On 27/06/2019 09:37, Roger Pau Monné wrote: > On Wed, Jun 26, 2019 at 08:02:12PM +0100, Andrew Cooper wrote: >> From: Sergey Dyasli <sergey.dya...@citrix.com> >> >> Otherwise hvm_set_cr0() will check the wrong CR4 bits (L1 instead of L2 >> and vice-versa). >> >> Signed-off-by: Sergey Dyasli <sergey.dya...@citrix.com> >> Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com> > Reviewed-by: Roger Pau Monné <roger....@citrix.com> > >> --- >> CC: Jan Beulich <jbeul...@suse.com> >> CC: Wei Liu <w...@xen.org> >> CC: Roger Pau Monné <roger....@citrix.com> >> CC: Jun Nakajima <jun.nakaj...@intel.com> >> CC: Kevin Tian <kevin.t...@intel.com> >> >> I found this patch languishing in the XenServer patchqueue, and Sergey is OoO >> so I'm submitting it on his behalf. >> >> Without this change, nested virt is broken when L1 and L2 differ in their use >> of PCID. >> >> This is only a stopgap solution - it resolves the PCID issue without >> introducing other issues, but the proper fix needs to consider all control >> bits at once, rather than considering a vmentry/exit as a sequence of changes >> of discrete registers. > The current approach seems prone to such ordering issues, and I don't > see a way to make it more robust while keeping the current approach, > so I guess setting all the registers state and then evaluating them > would make more sense and prevent this kind of mistakes.
I'm pretty sure that when we start doing all the checks that we should be doing, there will be combinations which can't be expressed as a non-faulting sequence of writes to cr0, cr4 and efer. Unfortunately, there is a load of nested virt prep work to do before implementing an approach like this becomes viable. Hence the stopgap solution in the meantime. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
