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

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

Le 29/12/2025 à 15:16, Jan Beulich a écrit :
> On 29.12.2025 13:39, Teddy Astie wrote:
>> Le 29/12/2025 à 09:24, Jan Beulich a écrit :
>>> On 28.12.2025 13:49, Teddy Astie wrote:
>>>> --- 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. */
>>>
>>> Naming-wise, do we really want to tie this to AMD (and hence exclude other
>>> vendors, or require yet another bit to be allocated later)?
>>
>> This is SEV-ES/SNP only, I don't think the same bit can be reused for
>> another technology (unless it also uses the GHCB MSR). As the guest
>> can't even check if it is Intel or AMD CPU at this point (if running
>> under SEV-ES or SEV-SNP).
>
> If it was just telling AMD from Intel, that would be possible. There are
> a few well-known differences in how certain instructions behave [1]. But
> here you aren't after telling apart the vendors; you want to know whether
> you're (fundamentally) on SVM or VT-x.
>
> Of course I have to admit that I find it quite irritating that in order
> to execute CPUID one has to have a #VC handler properly set up. This
> inverses the typical flow of events. Did they really not think of some
> replacement for at least the most basic information?
>

Yes, but only with more information beforehand.

Regarding the #VC approach, the negociation example also state this
 > The above example is just one way to perform the GHCB negotiation for
an SEV-ES guest. For example, you could use the GHCBInfo = 0x004 CPUID
Request to obtain actual values for the CPUID instructions executed by
the guest. Or you could use the GHCBInfo = 0x002 Request for SEV
Information if MSR 0xc001_0130 does not contain the GHCBInfo = 0x001 SEV
Information.

But that only works as long as you know GHCB MSR is available; which you
may be able to check through SEV_STATUS MSR; but this MSR is only
meaningful on CPUs that supports SEV (APM says the hypervisor cannot
intercept these MSRs). This proposal aims to give this information to
the guest through the start_info structure.

Under SEV-ES/SNP, the hypervisor cannot fake EFER MSR which in this case
may have forced guest-visible EFER:SVME, it could be a way to check for
SEV-ES for but it's quite hacky and fragile.
(I still need to test this though)

> Jan
>
> [1] Of course, such details can change going forward. Vendors did alter
> the behavior of certain insns in the past.
>


--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech