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.
