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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
