[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH for-9.1 v1 0/3] Add SEV/SEV-ES machine compat options for KVM
From: |
Paolo Bonzini |
Subject: |
Re: [PATCH for-9.1 v1 0/3] Add SEV/SEV-ES machine compat options for KVM_SEV_INIT2 |
Date: |
Thu, 11 Apr 2024 19:35:49 +0200 |
On Wed, Apr 10, 2024 at 1:08 AM Michael Roth <michael.roth@amd.com> wrote:
>
> These patches are also available at:
>
> https://github.com/amdese/qemu/commits/sev-init-legacy-v1
>
> and are based on top Paolo's qemu-coco-queue branch containing the
> following patches:
A more complete version of patch 2 was already on the list, so I
queued 1 and 3 to qemu-coco-queue.
Thanks!
Paolo
>
> [PATCH for-9.1 00/26] x86, kvm: common confidential computing subset
> https://lore.kernel.org/all/20240322181116.1228416-1-pbonzini@redhat.com/T/
>
> Overview
> --------
>
> With the following patches applied from qemu-coco-queue:
>
> https://lore.kernel.org/all/20240319140000.1014247-1-pbonzini@redhat.com/
>
> QEMU version 9.1+ will begin automatically making use of the new
> KVM_SEV_INIT2 API for initializing SEV and SEV-ES (and eventually, SEV-SNP)
> guests verses the older KVM_SEV_INIT/KVM_SEV_ES_INIT interfaces.
>
> However, the older interfaces would silently avoid sync'ing FPU/XSAVE state
> set by QEMU to each vCPU's VMSA prior to encryption. With KVM_SEV_INIT2,
> this state will now be synced into the VMSA, resulting in measurements
> changes and, theoretically, behaviorial changes, though the latter are
> unlikely to be seen in practice. The specific VMSA changes are documented
> in the section below for reference.
>
> This series implements machine compatibility options for SEV/SEV-ES so that
> only VMs created with QEMU 9.1+ will make use of KVM_SEV_INIT2 so that VMSA
> differences can be accounted for beforehand, and older machine types will
> continue using the older interfaces to avoid unexpected measurement
> changes.
>
> Specific VMSA changes
> ---------------------
>
> With KVM_SEV_INIT2, rather than 0, QEMU/KVM will instead begin setting the
> following fields in the VMSA before measurement/encryption:
>
> VMSA byte offset [1032:1033] = 80 1f (MXCSR, Multimedia Control Status
> Register)
> VMSA byte offset [1040:1041] = 7f 03 (FCW, FPU/x86 Control Word)
>
> Setting FCW (FPU/x86 Control Word) to 0x37f is consistent with 11.5.7 of
> APM Volume 2. MXCSR reset state is not defined for XSAVE, but QEMU's 0x1f80
> value is consistent with machine reset state documented in APM Volume 2
> 4.2.2. As such, it is reasonable to begin including these in the VMSA
> measurement calculations.
>
> NOTE: section 11.5.7 also documents that FTW should be all 1's, whereas
> QEMU currently sets all zeroes. Should that be changed as part of
> this, or are there other reasons for setting 0?
>
> Thanks,
>
> Mike
>
> ----------------------------------------------------------------
> Michael Roth (3):
> i386/sev: Add 'legacy-vm-type' parameter for SEV guest objects
> hw/i386: Add 9.1 machine types for i440fx/q35
> hw/i386/sev: Use legacy SEV VM types for older machine types
>
> hw/i386/pc.c | 5 +++++
> hw/i386/pc_piix.c | 13 ++++++++++++-
> hw/i386/pc_q35.c | 12 +++++++++++-
> include/hw/i386/pc.h | 3 +++
> qapi/qom.json | 11 ++++++++++-
> target/i386/sev.c | 19 ++++++++++++++++++-
> 6 files changed, 59 insertions(+), 4 deletions(-)
>
>
>