Re: [RFC PATCH] pvh: Introduce SIF_HVM_GHCB for SEV-ES/SNP guests

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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.