mbox series

[0/3] KVM: support the cpu feature FLUSH_L1D

Message ID 20230201132905.549148-1-eesposit@redhat.com
Headers
Series KVM: support the cpu feature FLUSH_L1D |

Message

Emanuele Giuseppe Esposito Feb. 1, 2023, 1:29 p.m. UTC 
  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(-)

Comments

Paolo Bonzini March 14, 2023, 1:29 p.m. UTC | #1 
Queued, thanks.

Paolo
Jim Mattson March 20, 2023, 4:52 p.m. UTC | #2 
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?
Emanuele Giuseppe Esposito March 21, 2023, 8:40 a.m. UTC | #3 
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
Paolo Bonzini March 21, 2023, 9:43 a.m. UTC | #4 
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
Jim Mattson March 21, 2023, 6:30 p.m. UTC | #5 
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. :)