Re: [Xen-devel] [VMI] Possible race-condition in altp2m APIs

[Mathieu Tarral <mathieu.tarral@xxxxxxxxxxxxxx>]

Le mardi, mai 7, 2019 2:01 PM, Mathieu Tarral <mathieu.tarral@xxxxxxxxxxxxxx> a 
écrit :

> > Given how many EPT flushing bugs I've already found in this area, I 
> > wouldn't be surprised if there are further ones lurking.  If it is an EPT 
> > flushing bug, this delta should make it go away, but it will come with a 
> > hefty perf hit.
> >
> > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> > index 283eb7b..019333d 100644
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -4285,9 +4285,7 @@ bool vmx_vmenter_helper(const struct cpu_user_regs 
> > *regs)
> >              }
> >          }
> >
> > -        if ( inv )
> > -            __invept(inv == 1 ? INVEPT_SINGLE_CONTEXT : INVEPT_ALL_CONTEXT,
> > -                     inv == 1 ? single->eptp          : 0);
> > +        __invept(INVEPT_ALL_CONTEXT, 0);
> >      }
> >
> >   out:
>
> I can give this a try, and see if it resolves the problem !

Just tested, on Xen 4.12.0, and the bug is still here.
Windows 7 is having BSODs with 4 VCPUs.
I didn't noticed a hefty performance impact though.

Do we have other caches to invalidate ?
Something else that i should test ?

I don't feel comfortable digging into Xen's code, especially for something as 
complicated as page table and memory management,
increased by the complexity of altp2m.
What i can do however, is test your ideas and patches and report the 
information I can gather on this issue.

Note: I tested with the latest commits on Drakvuf/master, especially:
"Add a VM pause for shadow copy refresh operation"
https://github.com/tklengyel/drakvuf/pull/626

@tamas, did you made this patch to fix these kind of race conditions issue that 
i'm reporting ?
Or was it totally unrelated ?

Thanks,
Mathieu

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel