Re: [PATCH 1/5] i386/sev: Add sev-emulated QOM object with TCG support

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Mar 17, 2026 at 12:38:36PM +0100, Tommaso Califano wrote:
> With this change it is possible to run a VM with the SEV CPUID active
> adding:
> 
>     -accel tcg \
>     -object sev-emulated,id=sev0,cbitpos=47,reduced-phys-bits=1 \
>     -machine memory-encryption=sev0

snip

> diff --git a/qapi/qom.json b/qapi/qom.json
> index c653248f85..35cda819ec 100644
> --- a/qapi/qom.json
> +++ b/qapi/qom.json
> @@ -1057,6 +1057,19 @@
>              '*handle': 'uint32',
>              '*legacy-vm-type': 'OnOffAuto' } }
>  
> +##
> +# @SevEmulatedProperties:
> +#
> +# Properties for sev-emulated objects.
> +# This object functionally emulates AMD SEV hardware via TCG, so
> +# it does not require real hardware to run.
> +#
> +# Since: 10.1.0
> +##
> +{ 'struct': 'SevEmulatedProperties',
> +  'base': 'SevGuestProperties',
> +  'data': {}}

This is deriving 'sev-emulated' from 'sev-guest' which means it
supports all the properties that 'sev-guest' does, which for
the record is:

 sev-guest options:
  dh-cert-file=<string>  - guest owners DH certificate (encoded with base64)
  kernel-hashes=<bool>   - add kernel hashes to guest firmware for measured Linux boot
  legacy-vm-type=<OnOffAuto> - use legacy VM type to maintain measurement compatibility with older QEMU or kernel versions.
  session-file=<string>  - guest owners session parameters (encoded with base64)
  sev-device=<string>    - SEV device to use


Of those properties

 * dh-cert-file + session-file are traditionally used
   as a means to transfer the TIK+TEK to the SEV firmware,
   with wrapping to protect them from the hypervisor.

   These can't be used with sev-emulated, as implemented,
   since they require a key derivation  from the PDH, a
   concept which IIUC is not implemented in this series.

   Instead, in a later patch 'tik' and 'tek' properties
   are added to 'sev-emulated', and to pass the TIK+TEK
   in clear text.

 * sev-device + legacy-vm-type - these are only relevant
   to the KVM integration, so not applicable for emulation

 * kernel-hashes - would be relevant if formally emulating
   LAUNCH_UPDATE_DATA for attestation, but IIUC, this is
   not done/used by this series
  

IOW, we're deriving from 'sev-guest' but AFAICT none of
its properties are relevant to the emulation. The
dh-cert-file and session-file could potentially be
relevant if implementing the PDH concept and key
derivation, but that's not done, instead the tik/tek
are passed explicitly.

What is the value we get from this sev-guest -> sev-emulated
inheritance ?  My gut feeling is that this perhaps isn't
the right way to be modelling things unless there's a plan
for future work that would benefit from them.

Another question related to modelling is whether there is
an intention to support SEV-SNP at a later date, would that
imply a sev-snp-emulated object type too ? If so, would it
inherit from sev-emulated or from sev-snp-guest ?

> +
>  ##
>  # @SevSnpGuestProperties:
>  #
> @@ -1241,6 +1254,7 @@
>      { 'name': 'secret_keyring',
>        'if': 'CONFIG_SECRET_KEYRING' },
>      'sev-guest',
> +    'sev-emulated',
>      'sev-snp-guest',
>      'thread-context',
>      's390-pv-guest',
> @@ -1318,6 +1332,7 @@
>        'secret_keyring':             { 'type': 'SecretKeyringProperties',
>                                        'if': 'CONFIG_SECRET_KEYRING' },
>        'sev-guest':                  'SevGuestProperties',
> +      'sev-emulated':               'SevEmulatedProperties',
>        'sev-snp-guest':              'SevSnpGuestProperties',
>        'tdx-guest':                  'TdxGuestProperties',
>        'thread-context':             'ThreadContextProperties',
> diff --git a/target/i386/sev.c b/target/i386/sev.c
> index 9dde972c11..2502e860e2 100644
> --- a/target/i386/sev.c
> +++ b/target/i386/sev.c
> @@ -51,6 +51,7 @@
>  
>  OBJECT_DECLARE_TYPE(SevCommonState, SevCommonStateClass, SEV_COMMON)
>  OBJECT_DECLARE_TYPE(SevGuestState, SevCommonStateClass, SEV_GUEST)
> +OBJECT_DECLARE_TYPE(SevEmulatedState, SevCommonStateClass, SEV_EMULATED)
>  OBJECT_DECLARE_TYPE(SevSnpGuestState, SevCommonStateClass, SEV_SNP_GUEST)
>  
>  /* hard code sha256 digest size */
> @@ -177,6 +178,21 @@ struct SevGuestState {
>      OnOffAuto legacy_vm_type;
>  };
>  
> +/**
> + * SevEmulatedState:
> + *
> + * The SevEmulatedState object is used for creating and managing a SEV emulated
> + * guest.
> + *
> + * # $QEMU \
> + *         -object sev-emulated,id=sev0 \
> + *         -machine ...,memory-encryption=sev0
> + */
> +
> +typedef struct SevEmulatedState {
> +    SevGuestState parent_obj;
> +} SevEmulatedState;
> +
>  struct SevSnpGuestState {
>      SevCommonState parent_obj;
>  
> @@ -2936,6 +2952,46 @@ sev_guest_instance_init(Object *obj)
>      sev_guest->legacy_vm_type = ON_OFF_AUTO_AUTO;
>  }
>  
> +static int sev_emulated_init(ConfidentialGuestSupport *cgs, Error **errp)
> +{
> +    SevCommonState *sev_common = SEV_COMMON(cgs);
> +
> +    /*
> +     * The cbitpos value will be placed in bit positions 5:0 of the EBX
> +     * register of CPUID 0x8000001F. We need to verify the range as the
> +     * comparison with the host cbitpos is missing.
> +     */
> +    if (sev_common->cbitpos < 32 ||
> +        sev_common->cbitpos > 63) {
> +        error_setg(errp, "%s: cbitpos check failed, requested '%d',"
> +                   "the firmware requires >=32",
> +                   __func__, sev_common->cbitpos);
> +        return -1;
> +    }
> +
> +    /*
> +     * The reduced-phys-bits value will be placed in bit positions 11:6 of
> +     * the EBX register of CPUID 0x8000001F, so verify the supplied value
> +     * is in the range of 1 to 63.
> +     */
> +    if (sev_common->reduced_phys_bits < 1 ||
> +        sev_common->reduced_phys_bits > 63) {
> +        error_setg(errp, "%s: reduced_phys_bits check failed,"
> +                   " it should be in the range of 1 to 63, requested '%d'",
> +                   __func__, sev_common->reduced_phys_bits);
> +        return -1;
> +    }
> +    cgs->ready = true;
> +    return 0;
> +}
> +
> +static void sev_emulated_class_init(ObjectClass *oc, const void *data)
> +{
> +    ConfidentialGuestSupportClass *klass = CONFIDENTIAL_GUEST_SUPPORT_CLASS(oc);
> +    /* Override the sev-common method that uses kvm */
> +    klass->kvm_init = sev_emulated_init;
> +}
> +
>  /* guest info specific sev/sev-es */
>  static const TypeInfo sev_guest_info = {
>      .parent = TYPE_SEV_COMMON,
> @@ -2945,6 +3001,14 @@ static const TypeInfo sev_guest_info = {
>      .class_init = sev_guest_class_init,
>  };
>  
> +/* emulated sev */
> +static const TypeInfo sev_emulated_info = {
> +    .parent = TYPE_SEV_GUEST,
> +    .name = TYPE_SEV_EMULATED,
> +    .instance_size = sizeof(SevEmulatedState),
> +    .class_init = sev_emulated_class_init
> +};
> +
>  static void
>  sev_snp_guest_get_policy(Object *obj, Visitor *v, const char *name,
>                           void *opaque, Error **errp)
> @@ -3207,6 +3271,7 @@ static void
>  sev_register_types(void)
>  {
>      type_register_static(&sev_common_info);
> +    type_register_static(&sev_emulated_info);
>      type_register_static(&sev_guest_info);
>      type_register_static(&sev_snp_guest_info);
>  }
> diff --git a/target/i386/sev.h b/target/i386/sev.h
> index 4358df40e4..839656e2be 100644
> --- a/target/i386/sev.h
> +++ b/target/i386/sev.h
> @@ -33,6 +33,7 @@ bool sev_snp_enabled(void);
>  #if !defined(CONFIG_USER_ONLY)
>  
>  #define TYPE_SEV_COMMON "sev-common"
> +#define TYPE_SEV_EMULATED "sev-emulated"
>  #define TYPE_SEV_GUEST "sev-guest"
>  #define TYPE_SEV_SNP_GUEST "sev-snp-guest"
>  
> -- 
> 2.53.0
> 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|