WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] RE: Biweekly VMX status report. Xen: #20255 & Xen0:#b6ba

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] RE: Biweekly VMX status report. Xen: #20255 & Xen0:#b6ba0...
From: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Date: Wed, 30 Sep 2009 10:08:10 +0100
Cc: "Xin, Xiaohui" <xiaohui.xin@xxxxxxxxx>, "'xen-devel@xxxxxxxxxxxxxxxxxxx'" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Xu, Jiajun" <jiajun.xu@xxxxxxxxx>, "Han, Weidong" <weidong.han@xxxxxxxxx>, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, "Li, Xin" <xin.li@xxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Delivery-date: Wed, 30 Sep 2009 02:10:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C6E8BFD0.16117%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <0463F45F3606F4428ED35AC8C709F92E089B659B27@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C6E8BFD0.16117%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
Hi,

At 07:57 +0100 on 30 Sep (1254297424), Keir Fraser wrote:
> On 30/09/2009 02:15, "Xu, Jiajun" <jiajun.xu@xxxxxxxxx> wrote:
> 
> >> 1. Booting guest with device assigned & EPT enabled cause xen crash
> >> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1518
> > 
> > For the above bug, it's a regression which does not exist in xen c/s 20187.
> > Could anyone help to fix it?
> > 
> > It's likely that the issue is introduced by the "pod for EPT" patches
> > (20191~20197).
> 
> It is caused by the addition of an assertion that p2m_is_locked_by_me in
> ept_sync_domain(). This was done because that function needs to be
> serialised, and we expected that anyone coming through set_p2m_entry() would
> have the p2m_lock held.

That's a very good assumption - it's the whole purpose of the p2m lock,
in fact.  And doubly so in the EPT code, which doesnt seem to take any
care over concurrency at all.

> So, we could 'fix' by giving ept_sync_domain() its own lock, but my
> suspicion would be that any paths through the p2m code that are not holding
> the p2m_lock probably need to be fixed. Adjusting p2m entries without the
> lock held sounds racey to me.

The {set,clear}_mmio_p2m_entry functions that were added for Vt-D MMIO
passthrough don't seem to do any locking.  (Actually, I don't see why
the mmio passthrough needs its own interface to the p2m at all.)
Untested but obvious fix attached.

Signed-off-by: Tim Deegan <Tim.Deegan@xxxxxxxxxx>

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

Attachment: p2m-lock
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel