Le 29/12/2025 à 09:24, Jan Beulich a écrit : > On 28.12.2025 13:49, Teddy Astie wrote: >> 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. > > But isn't this going to be needed for plain HVM anyway? >
This hint is only relevant for PVH entry point. The other guest boot paths can still rely on other mechanisms, e.g UEFI boot doesn't rely on the IDT approach and relies instead on the UEFI firmware to provide the early GHCB handler for the OS. From a Linux implementation standpoint, as PVH entry-point doesn't live in compressed/ boot code of Linux, the early-GHCB handlers (do_vc_no_ghcb and do_boot_stage2_vc) don't exist from there; so we either need to reimplement in non-compressed code or use another approach. >> --- 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). > Jan > Teddy -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
