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

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

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.

> 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?

> 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?

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.

> --
> 
> Some specialized boot process for SEV-SNP (e.g the one used 
> COCONUT-SVSM) relies on IGVM [1] with custom memory layouts, initial 
> pagetables, and so on.
> 
> [1] https://github.com/microsoft/igvm
> 
> >>>    ## AP startup ##
> >>>    
> >>>    AP startup can be performed using hypercalls or the local APIC if 
> >>> present.
> >>> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> >>> index 7f15204c38..9b84df573b 100644
> >>> --- a/xen/include/public/xen.h
> >>> +++ b/xen/include/public/xen.h
> >>> @@ -890,6 +890,8 @@ typedef struct start_info start_info_t;
> >>>    #define SIF_MOD_START_PFN (1<<3)  /* Is mod_start a PFN? */
> >>>    #define SIF_VIRT_P2M_4TOOLS (1<<4) /* Do Xen tools understand a virt. 
> >>> mapped */
> >>>                                       /* P->M making the 3 level tree 
> >>> obsolete? */
> >>> +#define SIF_HVM_GHCB      (1<<5)   /* Domain is SEV-ES/SNP guest that 
> >>> requires */
> >>> +                                   /* use of GHCB. */
> > 
> > A concern I have with this is that we are adding vendor-specific
> > terminology to what should otherwise be a vendor-agnostic interface.
> > 
> > There's already a fair amount of arch-specific information encoded in
> > there, so maybe not that much of a big deal.

If we end up getting this bit, I think it needs to be clear it's a
vendor specific feature: SIF_AMD_SEV_GHCB or similar would be better
IMO.

Thanks, Roger.