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

[Jan Beulich <jbeulich@xxxxxxxx>]

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?

Jan

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