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

["Teddy Astie" <teddy.astie@xxxxxxxxxx>]

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

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.

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

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

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

I was thinking in case another vendor (non-AMD) implements this
interface, but the MSR already has AMD_SEV in its name; so I'm ok using
something like SIF_AMD_SEV_GHCB.

> Thanks, Roger.
>



--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech