From: Wei Hu <weh@linux.microsoft.com>
To: linux-hyperv@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
"K. Y. Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
Long Li <longli@microsoft.com>
Subject: [PATCH v4 0/9] mshv: add SEV-SNP support for MSHV root partitions
Date: Mon, 31 Aug 2026 11:26:38 +0000 [thread overview]
Message-ID: <20260831112704.2851147-1-weh@linux.microsoft.com> (raw)
In-Reply-To: <20260825040505.826600-1-weh@linux.microsoft.com>
This series adds support for creating and managing AMD SEV-SNP
confidential virtual machines through the Microsoft Hypervisor root
partition driver.
The series adds fixed-size MSHV UAPI definitions, the required Microsoft
Hypervisor ABI definitions and hypercall helpers, partition ioctls,
capability discovery, processor-feature handling, ordered encrypted-memory
teardown, and nested-root SynIC handling.
Two prerequisite fixes now lead the series. The first makes memory-region
unmap ownership explicit and retains mappings, pinned pages, the partition,
and the module whenever checked hypervisor unmap cannot prove cleanup. The
second publishes and withdraws per-CPU SynIC pointers so interrupt readers
cannot observe mappings after initialization failure or CPU teardown.
The patches are based on the current hyperv-next branch.
Testing:
- Built all four affected x86 MSHV objects at every commit.
- Built the complete x86_64 kernel and the affected objects with W=1.
- Ran scripts/checkpatch.pl --strict on every patch with zero findings.
- Verified installed UAPI layouts in 64-bit and 32-bit userspace builds.
- Generated rust-vmm MSHV bindings from the installed kernel headers.
- Built the affected ARM64 objects with W=1 and no warnings.
- Passed Cloud Hypervisor's common_cvm::test_focal_simple_launch.
- Booted a four-vCPU SEV-SNP guest to login.
The development host needs two additional local runtime patches to boot
as a nested MSHV root partition: EFI HvLoader root-partition boot
enablement and the non-upstreamable nested-VMBus interrupt-vector
workaround. Neither patch is part of this series.
Changes since v3:
- Add checked memory-region unmap ownership as prerequisite patch 1. Keep
pages pinned and quarantine uncertain setup or teardown instead of
freeing memory that may remain child-accessible.
- Add SynIC pointer publication/withdrawal cleanup as prerequisite
patch 2.
- Rate-limit guest-triggerable PSP and isolated-page hypercall errors.
- Publish and consume driver readiness with release/acquire ordering.
- Make both array ioctls _IOWR interfaces with an MBZ input/completed
output
field, exact resumable progress, and defined no-rollback semantics.
- Preserve the exact asynchronous completion result, encode only bounded
repetition progress, and keep the distinct substatus out of result
bits.
- Check setup, explicit unmap, and teardown transitions; preserve list
and
kref ownership and quarantine any state whose safe release is
uncertain.
- Unmap child mappings before restoring host access for uninitialized as
well as initialized SNP partitions.
- Map hypervisor SynIC pages as decrypted shared-GPA mappings and
withdraw
per-CPU pointers before unmapping or freeing them.
- Validate VMSA and PSP GPAs before PFN conversion and retain the
existing
large-page alignment and physical-contiguity checks.
- Reject SNP isolation in intermediate commits until its complete ioctl
and
lifecycle implementation is present.
- Guard the SNP-only GPFN conversion helper so ARM64 W=1 builds do not
emit
an unused-function warning.
- Resolve additional adversarial-review findings: initialize common
region
locks for every region type, avoid mmap/remap lock inversion, validate
zero/oversized REP progress, and initialize all common copyout paths.
Two Sashiko findings were investigated and dismissed rather than papered
over.
Hyper-V consumes the PSP request input synchronously before returning
HV_STATUS_CALL_PENDING, so the shared per-CPU input page need not remain
reserved while waiting for completion. Also, MSHV's modify-SPA-host-access
operation transfers root-to-child SPA/SLAT ownership in Hyper-V; it does
not
perform an in-place SNP RMP transition on Linux-owned direct-map pages, so
kernel direct-map invalidation, encryption-attribute changes, and
shared-bit
rewrites would be incorrect here.
Link: https://lore.kernel.org/linux-hyperv/20260825040505.826600-1-weh@linux.microsoft.com/
Wei Hu (3):
mshv: retain memory regions until unmap succeeds
mshv: clear SynIC mappings before freeing them
mshv: set up own SynIC registers on a nested root partition
Wei Liu (6):
mshv: add SEV-SNP UAPI definitions
mshv: add SEV-SNP PSP request hypercall
mshv: add SEV-SNP isolated page hypercalls
mshv: wire SEV-SNP partition ioctls
mshv: detect and report SEV-SNP support at init
mshv: use safe partition CPU feature defaults
drivers/hv/mshv_regions.c | 160 +++--
drivers/hv/mshv_root.h | 50 +-
drivers/hv/mshv_root_hv_call.c | 303 +++++++--
drivers/hv/mshv_root_main.c | 1045 +++++++++++++++++++++++++++++---
drivers/hv/mshv_synic.c | 172 +++---
include/hyperv/hvgdk_mini.h | 31 +
include/hyperv/hvhdk.h | 124 +++-
include/hyperv/hvhdk_mini.h | 53 ++
include/uapi/linux/mshv.h | 111 +++-
9 files changed, 1813 insertions(+), 236 deletions(-)
base-commit: be0cfab740e58b70047ef6e7e3d578f00ed5d258
--
2.43.0
next prev parent reply other threads:[~2026-08-31 11:27 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 4:04 [PATCH v3 0/7] mshv: add SEV-SNP support for MSHV root partitions Wei Hu
2026-08-25 4:04 ` [PATCH v3 1/7] mshv: add SEV-SNP UAPI definitions Wei Hu
2026-08-25 4:04 ` [PATCH v3 2/7] mshv: add SEV-SNP PSP request hypercall Wei Hu
2026-08-25 4:17 ` sashiko-bot
2026-08-25 4:04 ` [PATCH v3 3/7] mshv: add SEV-SNP isolated page hypercalls Wei Hu
2026-08-25 4:04 ` [PATCH v3 4/7] mshv: wire SEV-SNP partition ioctls Wei Hu
2026-08-25 4:22 ` sashiko-bot
2026-08-25 4:04 ` [PATCH v3 5/7] mshv: detect and report SEV-SNP support at init Wei Hu
2026-08-25 4:19 ` sashiko-bot
2026-08-25 4:04 ` [PATCH v3 6/7] mshv: use safe partition CPU feature defaults Wei Hu
2026-08-25 4:04 ` [PATCH v3 7/7] mshv: set up own SynIC registers on a nested root partition Wei Hu
2026-08-25 4:20 ` sashiko-bot
2026-08-31 11:26 ` Wei Hu [this message]
2026-08-31 11:26 ` [PATCH v4 1/9] mshv: retain memory regions until unmap succeeds Wei Hu
2026-08-31 11:48 ` sashiko-bot
2026-09-01 12:04 ` [EXTERNAL] " Wei Hu
2026-08-31 11:26 ` [PATCH v4 2/9] mshv: clear SynIC mappings before freeing them Wei Hu
2026-08-31 11:26 ` [PATCH v4 3/9] mshv: add SEV-SNP UAPI definitions Wei Hu
2026-08-31 11:26 ` [PATCH v4 4/9] mshv: add SEV-SNP PSP request hypercall Wei Hu
2026-08-31 11:26 ` [PATCH v4 5/9] mshv: add SEV-SNP isolated page hypercalls Wei Hu
2026-08-31 11:53 ` sashiko-bot
2026-08-31 11:26 ` [PATCH v4 6/9] mshv: wire SEV-SNP partition ioctls Wei Hu
2026-08-31 12:07 ` sashiko-bot
2026-08-31 11:26 ` [PATCH v4 7/9] mshv: detect and report SEV-SNP support at init Wei Hu
2026-08-31 11:26 ` [PATCH v4 8/9] mshv: use safe partition CPU feature defaults Wei Hu
2026-08-31 11:26 ` [PATCH v4 9/9] mshv: set up own SynIC registers on a nested root partition Wei Hu
2026-08-31 12:09 ` sashiko-bot
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=20260831112704.2851147-1-weh@linux.microsoft.com \
--to=weh@linux.microsoft.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=wei.liu@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox