From: Melody Wang <huibo.wang@amd.com>
To: Ard Biesheuvel <ardb@kernel.org>, x86@kernel.org
Cc: LKML <linux-kernel@vger.kernel.org>,
Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [PATCH v3 0/8] Alternate Injection: Secure Interrupt Delivery for SEV-SNP Guests - Guest Support
Date: Thu, 24 Sep 2026 11:34:41 -0700 [thread overview]
Message-ID: <43674b3b-15a5-494c-b1de-041070b1e816@amd.com> (raw)
In-Reply-To: <1a64a4fb-c14b-454f-a89c-43112b01d187@app.fastmail.com>
Hi Ard,
On 9/23/26 1:56 PM, Ard Biesheuvel wrote:
> This may be a bit of a 'back to the drawing board' remark, but if opting
> in to this alternate injection scheme can only be done from the EFI firmware
> before ExitBootServices(), couldn't we wrap all this logic into an OVMF
> protocol instead? That way, the EFI stub can just invoke it if it exists,
> and what happens under the hood as a result is entirely under the control of
> the firmware.
Let me try to explain and please ask if anything's not clear because
this is a complex topic:
When a SEV-SNP guest starts, a Secure VM Service Module running at VMPL0
(higher privilege level than the guest's) is executed first. That's a
paravisor, see here for a possible explanation:
https://ksayid.github.io/confidential-computing-notes/docs/core/paravisor/.
That paravisor will boot OVMF, and then OVMF will boot the guest kernel.
The SVSM must know the Alternate Injection choice of the first component
which is the OVMF, so it will be able to enable Alternate Injection in
the guest VMSA and record OVMF's registration.
The guest kernel should be able to make its own independent decision
about whether to use Alternate Injection or not. If the kernel wants it,
the kernel must register itself — this registration is performed in
guest kernel code so that it remains under the guest kernel's control.
The guest kernel needs to register Alternate Injection before
ExitBootServices() so the SVSM registration counter always reflects the
correct, current state of Alternate Injection across the OVMF-to-kernel
hand-off.
But if we leave the OVMF to decide for the guest kernel, that is
violating the confidential computing principles of the guest being in
control.
I hope this makes more sense.
Thanks,
Melody.
next prev parent reply other threads:[~2026-09-24 18:34 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-20 18:12 Melody Wang
2026-09-20 18:12 ` [PATCH v3 1/8] x86/sev: Make SVSM calls preemption-safe Melody Wang
2026-09-20 18:16 ` Melody Wang
2026-09-20 18:12 ` [PATCH v3 2/8] x86/sev: Add support for Alternate Injection Melody Wang
2026-09-20 18:16 ` Melody Wang
2026-09-20 18:16 ` [PATCH v3 0/8] Alternate Injection: Secure Interrupt Delivery for SEV-SNP Guests - Guest Support Melody Wang
2026-09-20 18:16 ` [PATCH v3 3/8] x86/apic: Add an SVSM APIC driver Melody Wang
2026-09-22 1:31 ` Melody Wang
2026-09-23 20:31 ` Borislav Petkov
2026-09-20 18:16 ` [PATCH v3 4/8] x86/sev: Route unsupported APIC register accesses to the hypervisor APIC emulation Melody Wang
2026-09-20 18:16 ` [PATCH v3 5/8] x86/sev: Add a function to contain all SEV-specific setup operations Melody Wang
2026-09-20 18:16 ` [PATCH v3 6/8] x86/sev: Register the guest with the SVSM APIC protocol Melody Wang
2026-09-23 20:46 ` Melody Wang
2026-09-20 18:16 ` [PATCH v3 7/8] x86/sev: Allow the guest to configure interrupt vectors for the hypervisor Melody Wang
2026-09-23 20:46 ` Melody Wang
2026-09-20 18:17 ` [PATCH v3 8/8] x86/sev: Indicate that Alternate Injection is supported in the guest Melody Wang
2026-09-23 20:56 ` [PATCH v3 0/8] Alternate Injection: Secure Interrupt Delivery for SEV-SNP Guests - Guest Support Ard Biesheuvel
2026-09-24 18:34 ` Melody Wang [this message]
2026-09-24 19:06 ` Ard Biesheuvel
2026-09-25 4:47 ` Borislav Petkov
2026-09-25 5:44 ` Ard Biesheuvel
2026-09-25 5:47 ` Borislav Petkov
2026-09-28 2:55 ` Melody Wang
2026-09-28 7:14 ` Ard Biesheuvel
2026-09-28 19:34 ` Melody Wang
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=43674b3b-15a5-494c-b1de-041070b1e816@amd.com \
--to=huibo.wang@amd.com \
--cc=ardb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=thomas.lendacky@amd.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®