From: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
To: linux-kernel@vger.kernel.org
Cc: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>,
Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
Tianyu Lan <Tianyu.Lan@microsoft.com>,
Michael Kelley <mikelley@microsoft.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, linux-hyperv@vger.kernel.org,
Brijesh Singh <brijesh.singh@amd.com>,
Michael Roth <michael.roth@amd.com>,
Ashish Kalra <ashish.kalra@amd.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
linux-crypto@vger.kernel.org, Joerg Roedel <joro@8bytes.org>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
iommu@lists.linux.dev
Subject: [RFC PATCH v2 0/7] Support nested SNP KVM guests on Hyper-V
Date: Mon, 13 Feb 2023 10:33:55 +0000 [thread overview]
Message-ID: <20230213103402.1189285-1-jpiotrowski@linux.microsoft.com> (raw)
This patch series enables SNP-host support when running on Hyper-V, which
allows launching SNP guests while running as a nested hypervisor. This works
with SNP guest side support that was merged in v5.19, and the snp capable qemu
from AMD.
In this scenario the L0 hypervisor is Hyper-V, L1 is KVM, and L2 is an SNP
guest. The code from this patchset runs in L1. L1 is not an SNP guest itself,
SNP guests are not capable of supporting virtualization.
Patch 1 deals with allocating an RMP table which is not provided by
firmware/hypervisor, but is needed by the kernel to keep track of page
assignment to guests and rmp page size. Patch 2 implements MSR-based
rmpupdate/psmash instructions which are meant for virtualized environments.
Patch 3 containts the logic to update the rmp table when rmpupdate/psmash is
issued. Patch 4 makes sure that the kernel does not disable SNP support during
early CPU init. Patch 5 allows SNP initialization to proceed when no iommus
are available. Patch 6 adds a quirk in psp command buffer handling, because of
differences in SNP firmware spec interpretation. Patch 7 adds handling for RMP
faults which occur as NPF and the L0 is not able to resolve the address that
the fault occurred at.
This series depends on:
- "Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support" (applies on top of RFC v7)
https://lore.kernel.org/lkml/20221214194056.161492-1-michael.roth@amd.com/
- "Support ACPI PSP on Hyper-V"
https://lore.kernel.org/lkml/20230213092429.1167812-1-jpiotrowski@linux.microsoft.com/
Changes since v1:
* added handling for rmp page faults that occur during copy_to_user() that
don't come with a proper fault address when running nested.
* fold IS_ENABLED() test into hv_needs_snp_rmp(), and use CONFIG_KVM_AMD_SEV
instead of CONFIG_AMD_MEM_ENCRYPT
* introduce snp_soft_rmptable() wrapper to remove core dependency on hyperv
specific code
* use msr_set_bit for SYSCFG_MEM_ENCRYPT bit instead of open coding
Jeremi Piotrowski (7):
x86/hyperv: Allocate RMP table during boot
x86/sev: Add support for NestedVirtSnpMsr
x86/sev: Maintain shadow rmptable on Hyper-V
x86/amd: Configure necessary MSRs for SNP during CPU init when running
as a guest
iommu/amd: Don't fail snp_enable when running virtualized
crypto: ccp - Introduce quirk to always reclaim pages after SEV-legacy
commands
x86/fault: Handle RMP faults with 0 address when nested
arch/x86/hyperv/hv_init.c | 5 +
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/hyperv-tlfs.h | 3 +
arch/x86/include/asm/mshyperv.h | 3 +
arch/x86/include/asm/msr-index.h | 2 +
arch/x86/include/asm/sev.h | 6 ++
arch/x86/kernel/cpu/amd.c | 5 +-
arch/x86/kernel/cpu/mshyperv.c | 47 +++++++++
arch/x86/kernel/sev.c | 150 ++++++++++++++++++++++++++---
arch/x86/mm/fault.c | 14 +++
drivers/crypto/ccp/sev-dev.c | 6 +-
drivers/crypto/ccp/sp-dev.h | 4 +
drivers/crypto/ccp/sp-platform.c | 1 +
drivers/iommu/amd/init.c | 6 ++
14 files changed, 240 insertions(+), 13 deletions(-)
--
2.25.1
next reply other threads:[~2023-02-13 10:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 10:33 Jeremi Piotrowski [this message]
2023-02-13 10:33 ` [RFC PATCH v2 1/7] x86/hyperv: Allocate RMP table during boot Jeremi Piotrowski
2023-02-13 10:33 ` [RFC PATCH v2 2/7] x86/sev: Add support for NestedVirtSnpMsr Jeremi Piotrowski
2023-02-13 10:33 ` [RFC PATCH v2 3/7] x86/sev: Maintain shadow rmptable on Hyper-V Jeremi Piotrowski
2023-02-13 10:33 ` [RFC PATCH v2 4/7] x86/amd: Configure necessary MSRs for SNP during CPU init when running as a guest Jeremi Piotrowski
2023-02-13 10:34 ` [RFC PATCH v2 5/7] iommu/amd: Don't fail snp_enable when running virtualized Jeremi Piotrowski
2023-02-13 10:34 ` [RFC PATCH v2 6/7] crypto: ccp - Introduce quirk to always reclaim pages after SEV-legacy commands Jeremi Piotrowski
2023-02-13 10:34 ` [RFC PATCH v2 7/7] x86/fault: Handle RMP faults with 0 address when nested Jeremi Piotrowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230213103402.1189285-1-jpiotrowski@linux.microsoft.com \
--to=jpiotrowski@linux.microsoft.com \
--cc=Tianyu.Lan@microsoft.com \
--cc=ashish.kalra@amd.com \
--cc=bp@alien8.de \
--cc=brijesh.singh@amd.com \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.roth@amd.com \
--cc=mikelley@microsoft.com \
--cc=mingo@redhat.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=wei.liu@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.