[lkml]   [2013]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[PATCH v3 0/3] KVM: prepare for future XSAVE extensions
As soon as the kernel will support the XSAVE extensions in Skylake
processors, we will want both userspace and the hypervisor to run
guests without showing any trace of the new features (because
support for them in the hypervisor will come later).

This series does exactly this. Patches 1 and 3 ensures that userspace
does not get access to features not supported in the hypervisor.
Patch 2 does the same for the guest.

The effect of these patches is already visible together with
the corresponding QEMU patches and a command line such as "-cpu
SandyBridge,-avx". Previously, the guest could still enable AVX via
xsetbv, and state would be sent by QEMU during migration. These patches
make sure that disabling AVX will really prevent the guest from using it,
which helps if you have to deal with migration from newer versions of
QEMU and the kernel to older versions. The QEMU patches set up the
guest's 0xd CPUID leaf, which also ensures that the kernel has the
necessary information.


rename supported_xcr0 field to guest_supported_xcr0
rename xstate_size field to guest_xstate_size
do not hardcode XSTATE_FPSSE in guest_supported_xcr0
handle missing 0xd leaf

Paolo Bonzini (3):
KVM: x86: mask unsupported XSAVE entries from leaf 0Dh index 0
KVM: x86: prevent setting unsupported XSAVE states
KVM: x86: only copy XSAVE state for the supported features

arch/x86/include/asm/kvm_host.h | 2 ++
arch/x86/kvm/cpuid.c | 36 +++++++++++++++++++++++++++++++++++-
arch/x86/kvm/x86.c | 29 ++++++++++++++++++++++-------
arch/x86/kvm/x86.h | 1 +
4 files changed, 60 insertions(+), 8 deletions(-)


 \ /
  Last update: 2013-10-02 16:41    [W:0.079 / U:1.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site