lkml.org 
[lkml]   [2023]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH RFC v9 07/51] x86/sev: Add the host SEV-SNP initialization support
    From
    On 6/21/23 04:42, Borislav Petkov wrote:
    > On Sun, Jun 11, 2023 at 11:25:15PM -0500, Michael Roth wrote:
    >> From: Brijesh Singh <brijesh.singh@amd.com>
    >>
    >> The memory integrity guarantees of SEV-SNP are enforced through a new
    >> structure called the Reverse Map Table (RMP). The RMP is a single data
    >> structure shared across the system that contains one entry for every 4K
    >> page of DRAM that may be used by SEV-SNP VMs. APM2 section 15.36 details
    >
    > Rather say 'APM v2, section "Secure Nested Paging (SEV-SNP)"' because
    > the numbering is more likely to change than the name in the future. With
    > the name, people can find it faster.
    >
    >> a number of steps needed to detect/enable SEV-SNP and RMP table support
    >> on the host:
    >>
    >> - Detect SEV-SNP support based on CPUID bit
    >> - Initialize the RMP table memory reported by the RMP base/end MSR
    >> registers and configure IOMMU to be compatible with RMP access
    >> restrictions
    >> - Set the MtrrFixDramModEn bit in SYSCFG MSR
    >> - Set the SecureNestedPagingEn and VMPLEn bits in the SYSCFG MSR
    >> - Configure IOMMU
    >>
    >> RMP table entry format is non-architectural and it can vary by
    >> processor. It is defined by the PPR. Restrict SNP support to CPU
    >> models/families which are compatible with the current RMP table entry
    >> format to guard against any undefined behavior when running on other
    >> system types. Future models/support will handle this through an
    >> architectural mechanism to allow for broader compatibility.
    >
    > I'm guessing this is all for live migration between SNP hosts. If so,
    > then there will have to be a guest API to handle the differences.
    >
    >> SNP host code depends on CONFIG_KVM_AMD_SEV config flag, which may be
    >> enabled even when CONFIG_AMD_MEM_ENCRYPT isn't set, so update the
    >> SNP-specific IOMMU helpers used here to rely on CONFIG_KVM_AMD_SEV
    >> instead of CONFIG_AMD_MEM_ENCRYPT.
    >
    > Does that mean that even on CONFIG_AMD_MEM_ENCRYPT=n kernels, host SNP
    > can function?

    Yes, because CONFIG_AMD_MEM_ENCRYPT is mainly for dealing with the
    encryption bit.

    >
    > Do we even want that?

    We support that today with SEV and SEV-ES guests. The host/hypervisor
    kernel does not need CONFIG_AMD_MEM_ENCRYPT=y in order to run SEV guests.

    >
    > I'd expect that a host SNP kernel should have SME enabled too even
    > though it is not absolutely necessary.

    I recommend using TSME over SME.

    Thanks,
    Tom

    >
    >> Co-developed-by: Ashish Kalra <ashish.kalra@amd.com>
    >> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
    >> Co-developed-by: Tom Lendacky <thomas.lendacky@amd.com>
    >> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    >> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
    >> [mdr: rework commit message to be clearer about what patch does, squash
    >> in early_rmptable_check() handling from Tom]
    >> Signed-off-by: Michael Roth <michael.roth@amd.com>
    >> ---
    >> arch/x86/coco/Makefile | 1 +
    >> arch/x86/coco/sev/Makefile | 3 +
    >> arch/x86/coco/sev/host.c | 212 +++++++++++++++++++++++
    >> arch/x86/include/asm/disabled-features.h | 8 +-
    >> arch/x86/include/asm/msr-index.h | 11 +-
    >> arch/x86/include/asm/sev.h | 2 +
    >> arch/x86/kernel/cpu/amd.c | 19 ++
    >> drivers/iommu/amd/init.c | 2 +-
    >> include/linux/amd-iommu.h | 2 +-
    >> 9 files changed, 256 insertions(+), 4 deletions(-)
    >> create mode 100644 arch/x86/coco/sev/Makefile
    >> create mode 100644 arch/x86/coco/sev/host.c
    >
    > Ignored review comments here:
    >
    > https://lore.kernel.org/r/Y9ubi0i4Z750gdMm@zn.tnic
    >
    > Ignoring this one for now too.
    >

    \
     
     \ /
      Last update: 2023-06-21 16:39    [W:3.476 / U:0.300 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site