On Sat, 11 Aug 2018 at 23:19, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > On Sat, 11 Aug 2018, Mikhail Gavrilov wrote: > > > /* > > > * If this vCPU has touched SPEC_CTRL, restore the guest's value if > > > * it's non-zero. Since vmentry is serialising on affected CPUs, there > > > @@ -5590,6 +5588,8 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu) > > > */ > > > x86_spec_ctrl_set_guest(svm->spec_ctrl, svm->virt_spec_ctrl); > > > > > > + local_irq_enable(); > > > + > > > asm volatile ( > > > "push %%" _ASM_BP "; \n\t" > > > "mov %c[rbx](%[svm]), %%" _ASM_BX " \n\t" > > > > > > > > > I am tested this patch, but it not help solve issue. > > New dmesg output is attached here. > > Bah, stupid me. Forgot to fix the other end of that function as > well. Complete fix below. > > Thanks, > > tglx > > 8<--------------- > diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c > index f059a73f0fd0..9799f86388e7 100644 > --- a/arch/x86/kvm/svm.c > +++ b/arch/x86/kvm/svm.c > @@ -5580,8 +5580,6 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu) > > clgi(); > > - local_irq_enable(); > - > /* > * If this vCPU has touched SPEC_CTRL, restore the guest's value if > * it's non-zero. Since vmentry is serialising on affected CPUs, there > @@ -5590,6 +5588,8 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu) > */ > x86_spec_ctrl_set_guest(svm->spec_ctrl, svm->virt_spec_ctrl); > > + local_irq_enable(); > + > asm volatile ( > "push %%" _ASM_BP "; \n\t" > "mov %c[rbx](%[svm]), %%" _ASM_BX " \n\t" > @@ -5712,12 +5712,12 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu) > if (unlikely(!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL))) > svm->spec_ctrl = native_read_msr(MSR_IA32_SPEC_CTRL); > > - x86_spec_ctrl_restore_host(svm->spec_ctrl, svm->virt_spec_ctrl); > - > reload_tss(vcpu); > > local_irq_disable(); > > + x86_spec_ctrl_restore_host(svm->spec_ctrl, svm->virt_spec_ctrl); > + > vcpu->arch.cr2 = svm->vmcb->save.cr2; > vcpu->arch.regs[VCPU_REGS_RAX] = svm->vmcb->save.rax; > vcpu->arch.regs[VCPU_REGS_RSP] = svm->vmcb->save.rsp; > Perfect, the issue was gone! Can I hope to see this patch in 4.18 kernel or already too late?
