On 14/02/2018 05:39, Tom Lendacky wrote: > On 2/13/2018 10:22 AM, Paolo Bonzini wrote: >> On 08/02/2018 23:58, Tom Lendacky wrote: >>> Create an entry in the new MSR as a feature framework to allow a guest to >>> recognize LFENCE as a serializing instruction on AMD processors. The MSR >>> can only be set by the host, any write by the guest will be ignored. A >>> read by the guest will return the value as set by the host. In this way, >>> the support to expose the feature to the guest is controlled by the >>> hypervisor. >>> >>> Signed-off-by: Tom Lendacky <thomas.lendacky@xxxxxxx> >>> --- >>> arch/x86/kvm/svm.c | 16 ++++++++++++++++ >>> arch/x86/kvm/x86.c | 6 ++++++ >>> 2 files changed, 22 insertions(+) >>> >>> @@ -4047,6 +4052,17 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr) >>> case MSR_VM_IGNNE: >>> vcpu_unimpl(vcpu, "unimplemented wrmsr: 0x%x data 0x%llx\n", ecx, data); >>> break; >>> + case MSR_F10H_DECFG: >>> + /* Only the host can set this MSR, silently ignore */ >>> + if (!msr->host_initiated) >>> + break; >> >> Just one thing I'm wondering, should we #GP if the guest attempts to >> clear MSR_F10H_DECFG_LFENCE_SERIALIZE? > > It would be more consistent with other entries to do "return 1" here > instead. The current kernel code that writes this bit is using > msr_set_bit(), so a #GP is caught and handled. That's also okay. We don't know about Windows though... Paolo
