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 :|
