>>> On 01.09.16 at 12:25, <andrew.coop...@citrix.com> 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 <jbeul...@suse.com> > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
