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 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. 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.dya...@citrix.com> Signed-off-by: George Dunlap <george.dun...@citrix.com> --- -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
