On Fri, Jan 09, 2026 at 10:31:57AM +0000, Teddy Astie wrote: > Le 09/01/2026 à 09:59, Roger Pau Monné a écrit : > > On Thu, Jan 08, 2026 at 07:12:48PM +0000, Teddy Astie wrote: > >> Le 08/01/2026 à 18:46, Roger Pau Monné a écrit : > >>> On Thu, Jan 08, 2026 at 04:50:51PM +0000, Teddy Astie wrote: > >>>> Le 28/12/2025 à 13:54, Teddy Astie a écrit : > >>>>> Under SEV, the pagetables needs to be post-processed to add the C-bit > >>>>> (to make the mapping encrypted). The guest is expected to query the > >>>>> C-bit > >>>>> through CPUID. However, under SEV-ES and SEV-SNP modes, this instruction > >>>>> now triggers #VC instead. The guest would need to setup a IDT very early > >>>>> and instead use the early-GHCB protocol to emulate CPUID, which is > >>>>> complicated. > >>> > >>> Possibly a stupid question, but how is this information expected to > >>> be propagated to the guest when there's a guest firmware and > >>> bootloader in use? > >>> > >>> How is OVMF and/or grub propagating this information between > >>> themselves and to Linux? > >>> > >> > >> When booting Linux with SEV+UEFI, at least during the UEFI services, the > >> UEFI firmware transparently handles #VC for the rest to allow it to > >> perform CPUID operation. > >> (with SEV-SNP CPUID page exposed with a specific UEFI mecanism) > > > > Hm, that's going to be cumbersome when using hvmloader in this > > scenario, as it makes extensive use of CPUID and hence would need to > > setup it's own #VC handler ahead of making use of CPUID. > > > > Or we must instead get rid of hvmloader. > > > > For plain SEV, hvmloader would need to run with paging (PAE or 4-level) > to properly handle encryption bit. But would also need Xen to handle > MMIO instructions (which has some quirks due to being in encrypted memory).
Does hvmloader really need encryption though? What sensitive data does hvmloader deal with that would require encryption. > For SEV-ES, #VC handler + GHCB is not only required for CPUID, but also > for VMMCALL, MMIO, some MSR accesses, ... > > It would be easier to not use hvmloader, especially since only UEFI > supports SEV and guests would still need to support (Xen-specific) SEV > bits to begin with. I would be very happy to relegate hvmloader to be used with SeaBIOS only, and to load OVMF directly for HVM guests. But I don't know what's missing for OVMF to be capable of that. I would think not much, since it's already almost working for PVH guests AFAIK. Maybe PCI enumeration, but OVMF must have a way of doing that already for other platforms I expect. > >> So overall, this proposal is only meaningful for PVH booting, everything > >> that comes after can be handled differently. > >> > >>> Are they relying on the CPUID discovery logic mentioned above, or > >>> there's some shadow infra used by KVM for example to already convey > >>> it? > >>> > >> > >> OVMF at its startup relies on #VC for emulating CPUID. > >> It then relies on GHCB MSR for getting SEV info/C-bit (but only with > >> SEV-ES). And under SEV-SNP, it uses "CPUID page" instead of GHCB > >> (PAGE_TYPE_CPUID in SEV-SNP firmware ABI specification). > >> > >> This is because SEV/GHCB specification recommends using CPUID page under > >> SEV-SNP (even though the same protocol as SEV-ES still works; but is > >> discouraged). > > > > In a previous reply to Jan you mention that Linux already has such > > handlers, but just for the decompressing code (and hence not reachable > > from the PVH entry point, that's already decompressed code). Would it > > be possible to share the handlers with the PVH entry point? > > > > Maybe, Linux already does this for few parts of SEV code (e.g > arch/x86/coco/sev/vc-shared.c being also included in > arch/x86/boot/compressed/sev-handle-vc.c). > > Everything we would need appears to be contained in > arch/x86/boot/compressed/mem_encrypt.S. I don't know that much about Linux whether it would be easy for the PVH entry point to re-use that code. > >> In GHCB Version 2 (SEV-SNP) > >>> The hypervisor may supply the encryption bit position using the SEV > >>> Information MSR protocol, > >>> but the guest should use the CPUID information supplied in the CPUID Page > >>> to determine the > >>> encryption bit position. > >> > >> But its location is unfortunately undefined in this specification and in > >> the OVMF case, hardcoded in firmware metadata. > >> > >>> Adding Xen side-channels when there's an architectural defined way to > >>> obtain the information is a duplication of interfaces, and could lead > >>> to issues in the long run. We can not possibly be adding all vendor > >>> SEV options to SIF_ flags just because they are cumbersome to fetch. > >>> I know this is just one right now, but we don't know whether more of > >>> those CPUID options would be needed at the start of day in the future. > >>> > >> > >> That exists for SEV-ES and SEV-SNP (even though complicated) but for > >> SEV-SNP, it would relies on discouraged mecanisms (GHCB CPUID Request). > >> > >> AFAIU, this flag is enough for setting up long mode and GHCB which is > >> what matters. There are some additional structures (e.g secret page and > >> CPUID page) which could in the future be eventually exposed as PVH > >> modules; which would be hopefully less intrusive. > > > > If my understating is correct, this is not needed for the initial > > implementation of SEV (when hypervisor doesn't implement ES or SNP > > guests can use CPUID), and hence it might be best to wait for the > > basic SEV implementation to be in the hypervisor before jumping into > > ES or SNP details? > > > > Correct; CPUID is handled normally when not running with SEV-ES/SNP. > > > AFAICT (from your Linux entry point patch) you end up needing both the > > CPUID and the GHCB ways of detecting SEV support, so one doesn't > > preclude the other. > > > > Both are needed if we want to support both SEV-ES and no-ES cases; but > if only SEV-ES+ is wanted, the CPUID path would never be taken with this > approach. Since in Xen we do want to support plain SEV (without ES extensions), I would focus initially on the CPUID path, because it would be needed anyway. Get that working on both Xen and Linux, and then discuss about any ES/SNP ABI additions. It seems premature to do ABI changes to accommodate ES/SNP support when not even plain SEV is supported. Thanks, Roger.
