| Message ID | 1515479117-44967-1-git-send-email-wei.w.wang@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 09/01/2018 07:25, Wei Wang wrote: > This patch shows an alternative approach to the one posted here: > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1580364.html > > The advantages are > 1) Simpler; > 2) More reasonable because this is used to fill the hardware security > hole, for all the x86 cpus that physically support the two CPUIDs, > which means the hole already exists physically. All the VMs should > use this feature no matter what CPU model they are using. So, exposing > the two CPUIDs as long as they are physically supported by the hardware, > and this doesn't require the QEMU side hardcode as usual. > > When the related feature bits are added to the kernel, and we can simply > change it to: > best->edx |= F(SPEC_CTRL) | F(PRED_CMD); Is this meant to replace the whole series or just patch 1/7? The functions in patch 1/7 are used later by vmx.c and svm.c. Paolo
On 01/09/2018 04:39 PM, Paolo Bonzini wrote: > On 09/01/2018 07:25, Wei Wang wrote: >> This patch shows an alternative approach to the one posted here: >> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1580364.html >> >> The advantages are >> 1) Simpler; >> 2) More reasonable because this is used to fill the hardware security >> hole, for all the x86 cpus that physically support the two CPUIDs, >> which means the hole already exists physically. All the VMs should >> use this feature no matter what CPU model they are using. So, exposing >> the two CPUIDs as long as they are physically supported by the hardware, >> and this doesn't require the QEMU side hardcode as usual. >> >> When the related feature bits are added to the kernel, and we can simply >> change it to: >> best->edx |= F(SPEC_CTRL) | F(PRED_CMD); > Is this meant to replace the whole series or just patch 1/7? The > functions in patch 1/7 are used later by vmx.c and svm.c. > The pointer should have pointed to 7/7 (not 1/7). Just patch 7/7 actually. Best, Wei
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 0099e10..c33d3d4 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -70,6 +70,8 @@ u64 kvm_supported_xcr0(void) /* These are scattered features in cpufeatures.h. */ #define KVM_CPUID_BIT_AVX512_4VNNIW 2 #define KVM_CPUID_BIT_AVX512_4FMAPS 3 +#define KVM_CPUID_BIT_SPEC_CTRL 26 +#define KVM_CPUID_BIT_STIBP 27 #define KF(x) bit(KVM_CPUID_BIT_##x) int kvm_update_cpuid(struct kvm_vcpu *vcpu) @@ -109,6 +111,9 @@ int kvm_update_cpuid(struct kvm_vcpu *vcpu) } } + if (cpuid_edx(0x7) & (KF(SPEC_CTRL) | KF(STIBP))) + best->edx |= KF(SPEC_CTRL) | KF(STIBP); + best = kvm_find_cpuid_entry(vcpu, 0xD, 0); if (!best) { vcpu->arch.guest_supported_xcr0 = 0;
This patch shows an alternative approach to the one posted here: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1580364.html The advantages are 1) Simpler; 2) More reasonable because this is used to fill the hardware security hole, for all the x86 cpus that physically support the two CPUIDs, which means the hole already exists physically. All the VMs should use this feature no matter what CPU model they are using. So, exposing the two CPUIDs as long as they are physically supported by the hardware, and this doesn't require the QEMU side hardcode as usual. When the related feature bits are added to the kernel, and we can simply change it to: best->edx |= F(SPEC_CTRL) | F(PRED_CMD); Signed-off-by: Wei Wang <wei.w.wang@intel.com> --- arch/x86/kvm/cpuid.c | 5 +++++ 1 file changed, 5 insertions(+)