From: "Melody (Huibo) Wang via groups.io" <huibo.wang=amd.com@groups.io>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: "Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
Ard Biesheuvel <ardb+tianocore@kernel.org>,
Jiewen Yao <jiewen.yao@intel.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Erdem Aktas <erdemaktas@google.com>, Min Xu <min.m.xu@intel.com>,
"Roth, Michael" <Michael.Roth@amd.com>, Ray Ni <ray.ni@intel.com>,
Jiaxin Wu <jiaxin.wu@intel.com>,
Zhiguang Liu <zhiguang.liu@intel.com>,
Dun Tan <dun.tan@intel.com>, Rahul Kumar <rahul1.kumar@intel.com>,
Star Zeng <star.zeng@intel.com>
Subject: [edk2-devel] Move X2APIC enablement from Pei to Sec phase
Date: Tue, 22 Apr 2025 09:44:25 -0700 [thread overview]
Message-ID: <78983d77-8c0d-41b7-98c0-bcf8117bf55e@amd.com> (raw)
Hi,
I am currently working on enabling Alternate Injection for AMD SEV-SNP guests and have encountered a design issue.
The Alternate Injection specification, which is still preliminary, defines a so-called SVSM APIC protocol through a subset
of X2APIC MSRs while timer support is configurable.
[ This means, if timer functionality is not supported, the guest must rely on the hypervisor to emulate timer
support through use of the #HV Timer GHCB protocol. ]
When the OVMF firmware starts, it is in XAPIC mode by default and then, later, during the init phase it switches the guest to X2APIC.
However, with Alternate Injection enabled, the OVMF in its very first phase - SEC - does XAPIC accesses.
The SVSM, however, which is part of the guest, uses the so-called SVSM APIC protocol which uses a subset of the X2APIC MSRs.
The OVMF, however, assumes it starts off in XAPIC memory-mapped mode and thus there's a protocol mismatch of sorts
because with Alternate Injection already enabled in the SEC phase, it mandates X2APIC MSR accesses.
The registers (timer registers) when not handled by SVSM will get routed to the hypervisor (KVM) which at that point is operating the guest
in XAPIC mode until the PEI phase switches to X2APIC.
If X2APIC enablement is moved from the PEI to the SEC phase, the problem can be resolved. I have tested it and it works.
However, I dont know if there is any concern or potential design issues with that move.
Do folks think this is ok to do - i.e., move the X2APIC enablement to the SEC phase?
Or do you have any suggestions for a better solution?
Please feel free to ask questions if some concepts are unclear and I'll gladly expand on them.
I am new to this, sorry If I have CCed too many people.
Thanks,
Melody
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#121284): https://edk2.groups.io/g/devel/message/121284
Mute This Topic: https://groups.io/mt/112386836/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
next reply other threads:[~2025-04-22 21:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-22 16:44 Melody (Huibo) Wang via groups.io [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-04-20 1:31 [edk2-devel] Move X2APIC enablement from Pei to Sec phase Wang, Huibo via groups.io
2025-04-22 9:13 ` Ard Biesheuvel via groups.io
2025-04-22 16:34 ` Wang, Huibo via groups.io
2025-04-22 21:26 ` Andrew Fish via groups.io
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-list 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=78983d77-8c0d-41b7-98c0-bcf8117bf55e@amd.com \
--to=devel@edk2.groups.io \
/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