[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RESEND] nested EPT: fix the handling of nested EPT.
At 10:22 +0000 on 19 Jun (1434709345), Li, Liang Z wrote: > > > > > xen/arch/x86/mm/p2m-ept.c | 4 ++++ > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m- > > ept.c > > > > > index 5133eb6..26293a0 100644 > > > > > --- a/xen/arch/x86/mm/p2m-ept.c > > > > > +++ b/xen/arch/x86/mm/p2m-ept.c > > > > > @@ -26,6 +26,7 @@ > > > > > #include <asm/p2m.h> > > > > > #include <asm/hvm/vmx/vmx.h> > > > > > #include <asm/hvm/vmx/vmcs.h> > > > > > +#include <asm/hvm/nestedhvm.h> > > > > > #include <xen/iommu.h> > > > > > #include <asm/mtrr.h> > > > > > #include <asm/hvm/cacheattr.h> > > > > > @@ -1076,6 +1077,9 @@ void ept_sync_domain(struct p2m_domain > > *p2m) > > > > > > > > > > ASSERT(local_irq_is_enabled()); > > > > > > > > > > + if ( nestedhvm_enabled(d) ) > > > > > + p2m_flush_nestedp2m(d); > > > > > > > > > > > > It seems like this should trigger when the nested EPT table itself > > > > is being populated, e.g. > > > > > > > > hvm_hap_nested_page_fault > > > > --> nestedhvm_hap_nested_page_fault > > > > --> nestedhap_fix_p2m (--> p2m_lock(p2m)) > > > > --> p2m_set_entry > > > > --> ept_set_entry > > > > --> ept_sync_domain > > > > --> p2m_flush_nestedp2m > > > > --> p2m_flush_table (--> p2m_lock(p2m)) > > > > > > > > which would deadlock on the nested table's p2m lock. What have I > > missed? > > > > > > Yes, you are right. > > > > > > Maybe we should add another condition checking, just like: > > > > > > struct vcpu *v = current; > > > > > > If(nestedhvm_enabled(d) && !nestedhvm_vcpu_in_guestmode(v) ) > > > p2m_flush_nestedp2m(d); > > > > > > > > > Or add a flag(is_nested_p2m) in the struct p2m_domain to mark a nested > > > EPT, and change the condition to: > > > If(nestedhvm_enabled(d) && p2m->is_nested_p2m ) > > > > Yes, I think this is the right check, but you shouldn't need to add any new > > flags: p2m_is_nestedp2m(p2m) will work. > > > > Also, in the next version of the patch, please describe what testing you've > > done. > > Hi Tim, > > I can boot the L2 guest successfully with my new patch, and I want to verify > that without the fixed patch, > there are some issue, but I don't know how to trigger the bug. Which case > should the test cover? > Could you give some suggestion? I'm not sure - I found the bug in the code, and not on a running system. I cn't even think of a way to provoke it without writing a malicious L1 guest. IMO if it doesn't break existing nested support that'll be enough testing. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |