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 v2 6/8] x86/sev: Register the guest with the SVSM APIC protocol
Date: Mon, 14 Sep 2026 19:04:13 -0700 [thread overview]
Message-ID: <3f4e75ed-9a4b-448c-adb4-5e2e8bae8b11@amd.com> (raw)
In-Reply-To: <8e4b05a5-61e7-4015-ab72-1e55156e1772@app.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 3699 bytes --]
Hi Ard,
On 9/14/26 1:06 PM, Ard Biesheuvel wrote:
> On Mon, 14 Sep 2026, at 02:57, Melody Wang wrote:
>> The SVSM APIC protocol supports 5 calls. SVSM_APIC_CONFIGURE_EMULATION
>> (shortened to SVSM_APIC_CONFIG_EMULATION for brevity), call 1, provides
>> the controls whether the guest can make use of the SVSM APIC protocol.
>>
>> Implement this call, and register Alternate Injection for the guest
>> by default.
>>
>> Signed-off-by: Melody Wang <huibo.wang@amd.com>
>> ---
>> arch/x86/boot/compressed/sev.c | 17 +++++++++++++++++
>> arch/x86/boot/compressed/sev.h | 6 ++++++
>> 2 files changed, 23 insertions(+)
>>
>
> Does this need to happen in the EFI stub and/or decompressor? We have swathes
> of early SEV-SNP boot code in the kernel proper; could it be done there?
Let me answer the question directly first:
Alternate Injection is used by both the guest firmware and the guest
kernel. Before we run the guest kernel, guest firmware - OVMF - is using
Alternate Injection for interrupts, etc.
So ExitBootServices() is a handoff boundary. When it is called, the
firmware's use of Alternate Injection ends. It must deregister its use
of Alternate Injection at this point since it can not assume anything
about the guest kernel that follows.
At this moment, if the guest kernel has not registered the use of
Alternate Injection, latter is disabled and can not be re-enabled.
So if the guest kernel wants Alternate Injection, it has to happen
before ExitBootServices().
I hope this answers the question, the rest below is a longer, more
detailed explanation which you don't necessarily need to read - only if
you're interested.
:)
Now here's the long explanation along with the spec on the matter:
There is an Alternate Injection spec (I'm attaching it because the
mailing list archives which hosted it, are not up currently) and it says
that Alternate Injection supports multiple guest runtimes, see the
"Negotiating Functionality" section.
When there is a handoff from a UEFI virtual firmware to a guest
operating system, the firmware, before terminating its execution must be
prepared to disable the use of Alternate Injection unless it knows the
guest kernel is prepared to continue use of Alternate Injection.
However, there is no mechanism for them to negotiate this directly, so
the SVSM APIC protocol supports a registration mechanism to determine
the behavior across handoff by using a registration counter.
The spec has an example how this mechanism might be used in the case of
transition from UEFI-based firmware to a guest OS:
"Prior to executing ExitBootServices, a guest OS that understands the
SVSM APIC Protocol should detect the availability of that protocol and
determine whether it is usable. If so, it should register its use of the
SVSM APIC Protocol.
During the execution of ExitBootServices, the firmware (which does not
know the intention of the guest OS) should deregister its use of the
SVSM APIC protocol. If the guest OS registered its intention to use
Alternate Injection, this call will not affect the current state of
Alternate Injection. If the guest OS did not declare its intention to
use Alternate Injection, then this call will disable Alternate Injection."
During the handoff, the firmware needs to deresgister its use of
Alternate Injection, so the registration counter can reflect the right
status of using Alternate Injection for runtimes. Once the registration
count reaches zero, Alternate Injection is disabled and cannot be
re-enabled, so if the guest OS wants Alternate Injection, it has to
register before ExitBootServices() to keep the count > 0.
I hope that makes sense.
--
Thanks,
Melody
[-- Attachment #2: Alternate Injection Support for SEV-SNP 20240619.pdf --]
[-- Type: application/pdf, Size: 115756 bytes --]
next prev parent reply other threads:[~2026-09-15 2:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 0:57 [PATCH v2 0/8] Alternate Injection: Secure Interrupt Delivery for SEV-SNP Guests - Guest Support Melody Wang
2026-09-14 0:57 ` [PATCH v2 1/8] x86/sev: Make SVSM calls preemption-safe Melody Wang
2026-09-14 0:57 ` [PATCH v2 2/8] x86/sev: Add support for Alternate Injection Melody Wang
2026-09-14 0:57 ` [PATCH v2 3/8] x86/apic: Add an SVSM APIC driver Melody Wang
2026-09-14 0:57 ` [PATCH v2 4/8] x86/sev: Route unsupported APIC register accesses to the hypervisor APIC emulation Melody Wang
2026-09-14 0:57 ` [PATCH v2 5/8] x86/sev: Add a function to contain all SEV-specific setup operations Melody Wang
2026-09-14 20:04 ` Ard Biesheuvel
2026-09-14 0:57 ` [PATCH v2 6/8] x86/sev: Register the guest with the SVSM APIC protocol Melody Wang
2026-09-14 20:06 ` Ard Biesheuvel
2026-09-15 2:04 ` Melody Wang [this message]
2026-09-15 7:44 ` Ard Biesheuvel
2026-09-14 0:57 ` [PATCH v2 7/8] x86/sev: Allow the guest to configure interrupt vectors for the hypervisor Melody Wang
2026-09-14 0:57 ` [PATCH v2 8/8] x86/sev: Indicate that Alternate Injection is supported in the guest 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=3f4e75ed-9a4b-448c-adb4-5e2e8bae8b11@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®