Re: [Xen-devel] [PATCH 2/9] x86/np2m: Have invept flush all np2m entries with the same base pointer

[Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>]

On Mon, 2017-10-02 at 11:07 +0100, George Dunlap wrote:
> On 10/02/2017 10:40 AM, George Dunlap wrote:
> > On 10/02/2017 10:37 AM, Sergey Dyasli wrote:
> > > On Fri, 2017-09-29 at 16:01 +0100, George Dunlap wrote:
> > > > nvmx_handle_invept() updates current's np2m just to flush it.  This is
> > > > not only wasteful, but ineffective: if several L2 vcpus share the same
> > > > np2m base pointer, they all need to be flushed (not only the current
> > > > one).
> > > 
> > > I don't follow this completely. L1 will use INVEPT on each vCPU that
> > > shares the same np2m pointer. The main idea here was not to update
> > > current's np2m just to flush it.
> > 
> > Hmm, yes the INVEPT thing is true.  But if that's the case, why do we
> > need np2m_flush_base() to loop over the whole list and flush all np2ms
> > with the same pointer?
> 
> Oh, nevermind -- you don't know which np2m is being used by this vcpu,
> so you have to flush all of the np2ms that match that base pointer.
> 
> What about this changelog:
> 
> ---
> x86/np2m: Flush p2m rather than switching on nested invept

It's not entirely clear what "switching" means here. But I fail to
think of any other good alternatives for the patch's subject.

> 
> At the moment, nvmx_handle_invept() updates the current np2m just to
> flush it.  Instead introduce a function, np2m_flush_base(), which will
> look up the np2m base pointer and call p2m_flush_table() instead.
> 
> Unfortunately, since we don't know which p2m a given vcpu is using, we
> must flush all p2ms that share that base pointer.

My reasoning was the same:

INVEPT from L1 happens outside of L02 vCPU's context and currently it's
impossible (because of scheduling) to detect the exact np2m object that
needs to be flushed.

> 
> Convert p2m_flush_table() into p2m_flush_table_locked() in order not
> to release the p2m_lock after np2m_base check.
> 
> Signed-off-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>
> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>
-- 
Thanks,
Sergey
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel