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

["Teddy Astie" <teddy.astie@vates.tech>]

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)

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

--

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.
>
> Thanks, Roger.
>


--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech