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

["Roger Pau Monné" <roger.pau@citrix.com>]

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?

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?

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.

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

Thanks, Roger.