Re: [Xen-devel] [PATCH v2 3/3] x86/levelling: Provide architectural OSXSAVE handling to masked native CPUID

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.09.16 at 12:25, <andrew.cooper3@xxxxxxxxxx> wrote:
> Contrary to c/s b2507fe7 "x86/domctl: Update PV domain cpumasks when setting
> cpuid policy", Intel CPUID masks are applied after fast forwarding hardware
> state, rather than before.  (All behaviour in this regard appears completely
> undocumented by both Intel and AMD).
> 
> Therefore, a set bit in the MSR causes hardware to be fast-forwarded, while a
> clear bit forces the guests view to 0, even if Xen's CR4.OSXSAVE is actually
> set.
> 
> This allows Xen to provide an architectural view of a guest kernels
> CR4.OSXSAVE setting to any native CPUID instruction issused by guest kernel or
> userspace, even when masking is used.
> 
> The masking value defaults to 1 (if the guest has XSAVE available) to cause
> fast-forwarding to occur for the HVM and idle vcpus.
> 
> When setting the MSRs, a PV guest kernel's choice of OXSAVE is taken into
> account, and clobbered from the MSR if not set.  This causes the
> fast-forwarding of Xen's CR4 state not to happen.
> 
> As a side effect however, levelling potentially need updating on all PV CR4
> changes.
> 
> Reported-by: Jan Beulich <JBeulich@xxxxxxxx>
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>


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