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

["Kay, Allen M" <allen.m.kay@xxxxxxxxx>]

I'm still seeing the same assertion failure with this patch on my NHM EP system.

(XEN) Xen call trace:
(XEN)    [<ffff82c4801b01a5>] ept_sync_domain+0x62/0x9c
(XEN)    [<ffff82c4801e559d>] ept_set_entry+0x6c1/0x7f6
(XEN)    [<ffff82c4801e5905>] ept_change_entry_emt_with_range+0x233/0x25e
(XEN)    [<ffff82c4801b0209>] vmx_set_uc_mode+0x2a/0x5d
(XEN)    [<ffff82c4801959c8>] hvm_set_uc_mode+0x31/0x38
(XEN)    [<ffff82c480195de1>] hvm_set_cr0+0x412/0x533
(XEN)    [<ffff82c4801b2a4d>] vmx_vmexit_handler+0xe8f/0x1b48
(XEN)    
(XEN) 
(XEN) ****************************************
(XEN) Panic on CPU 8:
(XEN) Assertion '(((get_cpu_info()->current_vcpu))->processor == (d->arch.p2m)->
locker)' failed at vmx.c:1242
(XEN) ****************************************


-----Original Message-----
From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx] 
Sent: Wednesday, September 30, 2009 2:08 AM
To: Keir Fraser
Cc: Xu, Jiajun; 'xen-devel@xxxxxxxxxxxxxxxxxxx'; Xin, Xiaohui; George Dunlap; 
Kay, Allen M; Han, Weidong; Li, Xin; Nakajima, Jun
Subject: Re: [Xen-devel] RE: Biweekly VMX status report. Xen: #20255 & 
Xen0:#b6ba0...

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.]

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