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

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

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