From: sashiko-bot@kernel.org
To: "Zack Rusin" <zack.rusin@broadcom.com>
Cc: "Eugenio Perez" <eperezma@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
kvm@vger.kernel.org, virtualization@lists.linux.dev
Subject: Re: [PATCH v1 2/2] x86/vmware: Decrypt steal-time storage before sharing it
Date: Wed, 16 Sep 2026 05:14:53 +0000 [thread overview]
Message-ID: <20260916051454.748B41F000FF@smtp.kernel.org> (raw)
In-Reply-To: <bbdb89067cd07d07fe4963ad229932faf87b0ef9.1789488039.git.zack.rusin@broadcom.com>
> VMware's steal-time counter must be in shared memory so the host can
> update it. Encrypted guests currently register its address without
> decrypting the storage. Move their setup to an early initcall, when the
> memory allocator is available for page-table splitting, but before
> secondary CPUs start. Leave ordinary guests' setup unchanged.
>
> Convert every possible CPU's storage before registering any address.
> Zero each object after conversion, since its contents may not survive
> conversion and the host initializes only the counter. Register the boot
> CPU with preemption disabled; the existing hotplug callbacks handle the
> others. If conversion or boot-CPU registration fails, attempt to re-encrypt
> all affected ranges, including a partially converted failing range, and
> disable steal time.
>
> TDX's conversion path requires directly mapped memory. Check all per-CPU
> objects before converting anything, and disable steal time if a TDX guest
> uses the page per-CPU allocator, which supplies vmalloc mappings. This
> also covers automatic fallback from the embedded allocator. AMD guests
> are unaffected by this restriction because their conversion path supports
> those mappings.
>
> Link: https://lore.kernel.org/r/20260309235250.2611115-5-alexey.makhalov@broadcom.com
> Co-developed-by: Bo Gan <bo.gan@broadcom.com>
> Signed-off-by: Bo Gan <bo.gan@broadcom.com>
> Co-developed-by: Alexey Makhalov <alexey.makhalov@broadcom.com>
> Signed-off-by: Alexey Makhalov <alexey.makhalov@broadcom.com>
> Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1789488039.git.zack.rusin@broadcom.com?part=2
next prev parent reply other threads:[~2026-09-16 5:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 5:05 [PATCH v1 0/2] x86/vmware: Share steal-time storage in encrypted guests Zack Rusin
2026-09-16 5:05 ` [PATCH v1 1/2] percpu: Use X86_MEM_ENCRYPT for decrypted per-CPU data Zack Rusin
2026-09-16 5:16 ` sashiko-bot
2026-09-16 11:14 ` Kiryl Shutsemau
2026-09-16 5:05 ` [PATCH v1 2/2] x86/vmware: Decrypt steal-time storage before sharing it Zack Rusin
2026-09-16 5:14 ` sashiko-bot [this message]
2026-09-16 12:18 ` [PATCH v1 0/2] x86/vmware: Share steal-time storage in encrypted guests Kiryl Shutsemau
2026-09-16 15:41 ` Zack Rusin
2026-09-17 14:11 ` Kiryl Shutsemau
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=20260916051454.748B41F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=eperezma@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=virtualization@lists.linux.dev \
--cc=zack.rusin@broadcom.com \
/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