arch/x86/kvm/cpuid.c | 2 +- arch/x86/kvm/svm/svm.c | 44 ++++++++++++++++-------- arch/x86/kvm/vmx/nested.c | 3 ++ arch/x86/kvm/vmx/vmx.c | 70 +++++++++++++++++++++++++-------------- 4 files changed, 80 insertions(+), 39 deletions(-)
As the title suggest, if the host cpu supports flush_l1d flag and QEMU/userspace wants to boot a VM with the same flag (or emulate same host features), KVM should be able to do so. Patch 3 is the main fix, because if flush_l1d is not advertised by KVM, a linux VM will erroneously mark /sys/devices/system/cpu/vulnerabilities/mmio_stale_data as vulnerable, even though it isn't since the host has the feature and takes care of this. Not sure what would happen in the nested case though. Patch 1 and 2 are just taken and refactored from Jim Mattison's serie that it seems was lost a while ago: https://patchwork.kernel.org/project/kvm/patch/20180814173049.21756-1-jmattson@google.com/ I thought it was worth re-posting them. Thank you, Emanuele Emanuele Giuseppe Esposito (3): kvm: vmx: Add IA32_FLUSH_CMD guest support kvm: svm: Add IA32_FLUSH_CMD guest support kvm: x86: Advertise FLUSH_L1D to user space arch/x86/kvm/cpuid.c | 2 +- arch/x86/kvm/svm/svm.c | 44 ++++++++++++++++-------- arch/x86/kvm/vmx/nested.c | 3 ++ arch/x86/kvm/vmx/vmx.c | 70 +++++++++++++++++++++++++-------------- 4 files changed, 80 insertions(+), 39 deletions(-) -- 2.39.1
On Wed, Feb 1, 2023 at 5:29 AM Emanuele Giuseppe Esposito <eesposit@redhat.com> wrote: > > As the title suggest, if the host cpu supports flush_l1d flag and > QEMU/userspace wants to boot a VM with the same flag (or emulate same > host features), KVM should be able to do so. > > Patch 3 is the main fix, because if flush_l1d is not advertised by > KVM, a linux VM will erroneously mark > /sys/devices/system/cpu/vulnerabilities/mmio_stale_data > as vulnerable, even though it isn't since the host has the feature > and takes care of this. Not sure what would happen in the nested case though. > > Patch 1 and 2 are just taken and refactored from Jim Mattison's serie that it > seems was lost a while ago: > https://patchwork.kernel.org/project/kvm/patch/20180814173049.21756-1-jmattson@google.com/ > > I thought it was worth re-posting them. What has changed since the patches were originally posted, and Konrad dissed them?
On Mon, Mar 20, 2023 at 5:52 PM Jim Mattson <jmattson@google.com> wrote:
> > Patch 1 and 2 are just taken and refactored from Jim Mattison's serie that it
> > seems was lost a while ago:
> > https://patchwork.kernel.org/project/kvm/patch/20180814173049.21756-1-jmattson@google.com/
> >
> > I thought it was worth re-posting them.
>
> What has changed since the patches were originally posted, and Konrad
> dissed them?
What has changed is that the reporting of mmio_stale_data now
piggybacks on flush_l1d as well.
if ((ia32_cap & ARCH_CAP_FB_CLEAR) ||
(boot_cpu_has(X86_FEATURE_MD_CLEAR) &&
boot_cpu_has(X86_FEATURE_FLUSH_L1D) &&
!(ia32_cap & ARCH_CAP_MDS_NO)))
mmio_mitigation = MMIO_MITIGATION_VERW;
else
mmio_mitigation = MMIO_MITIGATION_UCODE_NEEDED;
Maybe Intel only defines CPUID bits after a firstborn has been
sacriificed to the microcode gods?
Paolo
On Tue, Mar 21, 2023 at 2:43 AM Paolo Bonzini <pbonzini@redhat.com> wrote: > > On Mon, Mar 20, 2023 at 5:52 PM Jim Mattson <jmattson@google.com> wrote: > > > Patch 1 and 2 are just taken and refactored from Jim Mattison's serie that it > > > seems was lost a while ago: > > > https://patchwork.kernel.org/project/kvm/patch/20180814173049.21756-1-jmattson@google.com/ > > > > > > I thought it was worth re-posting them. > > > > What has changed since the patches were originally posted, and Konrad > > dissed them? > > What has changed is that the reporting of mmio_stale_data now > piggybacks on flush_l1d as well. > > if ((ia32_cap & ARCH_CAP_FB_CLEAR) || > (boot_cpu_has(X86_FEATURE_MD_CLEAR) && > boot_cpu_has(X86_FEATURE_FLUSH_L1D) && > !(ia32_cap & ARCH_CAP_MDS_NO))) > mmio_mitigation = MMIO_MITIGATION_VERW; > else > mmio_mitigation = MMIO_MITIGATION_UCODE_NEEDED; > > Maybe Intel only defines CPUID bits after a firstborn has been > sacriificed to the microcode gods? > > Paolo > Ha! As I wrote way back when, "It is more forward-thinking to provide this capability than it is not to." I feel vindicated. :)
Am 20/03/2023 um 17:52 schrieb Jim Mattson: > On Wed, Feb 1, 2023 at 5:29 AM Emanuele Giuseppe Esposito > <eesposit@redhat.com> wrote: >> >> As the title suggest, if the host cpu supports flush_l1d flag and >> QEMU/userspace wants to boot a VM with the same flag (or emulate same >> host features), KVM should be able to do so. >> >> Patch 3 is the main fix, because if flush_l1d is not advertised by >> KVM, a linux VM will erroneously mark >> /sys/devices/system/cpu/vulnerabilities/mmio_stale_data >> as vulnerable, even though it isn't since the host has the feature >> and takes care of this. Not sure what would happen in the nested case though. >> >> Patch 1 and 2 are just taken and refactored from Jim Mattison's serie that it >> seems was lost a while ago: >> https://patchwork.kernel.org/project/kvm/patch/20180814173049.21756-1-jmattson@google.com/ >> >> I thought it was worth re-posting them. > > What has changed since the patches were originally posted, and Konrad > dissed them? > From the upstream conversation, I honestly didn't really catch that Konrad dissed them. Or at least, I didn't read a valid reason for doing so, contrary to what Sean instead provided. I thought it was just forgotten. My bad, next time I will be more careful when trying to resume old patches :) Thank you, Emanuele
© 2016 - 2025 Red Hat, Inc.