Re: [PATCH] VMX: sync CPU state upon vCPU destruction

[Dario Faggioli <raistlin@linux.it>]

[-- Attachment #1.1: Type: text/plain, Size: 1495 bytes --]

On Fri, 2017-11-10 at 08:41 +0000, Sergey Dyasli wrote:
> On Thu, 2017-11-09 at 07:49 -0700, Jan Beulich wrote:
> > 
> This patch fixes only one particular issue and not the general
> problem.
> What if vmcs is cleared, possibly in some future code, at another
> place?
> 
Yes, that's what we were saying yesterday. Asynchronous code fiddling
with context, will have to make sure it syncs things properly. And we
need to keep an eye out for that.

> The original intent of vmx_vmcs_reload() is correct: it lazily loads
> the vmcs when it's needed. It's just the logic which checks for
> v->is_running inside vmx_ctxt_switch_from() is flawed: v might be
> "running" on another pCPU.
> 
> IMHO there are 2 possible solutions:
> 
>     1. Add additional pCPU check into vmx_ctxt_switch_from()
>
How? Checking v->processor is not an option as, AFAICS, this runs
without owning the scheduling lock, and hence processor can change
under your feet.

>     2. Drop v->is_running check inside vmx_ctxt_switch_from() making
>        vmx_vmcs_reload() unconditional.
> 
Well, that looks plausible to me. Although, I guess it will have, at
least potentially, an impact on performance (as other solutions
envisioned in the thread). Any idea how big the hit could be?

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel