Il 19/03/26 13:31, Markus Armbruster ha scritto:
> Tommaso Califano <[email protected]> writes:
>
>> QEMU's AMD SEV support requires KVM on costly AMD EPYC processors,
>> limiting development and testing to users with specialized server
>> hardware. This makes it hard to validate SEV guest behavior, like
>> OVMF boots or SEV-aware software, on common dev machines.
>> A solution to this is the emulation of SEV from the guest's
>> perspective using TCG.
>>
>> This change begins this process with the exposure of the SEV CPUID leaf.
>> In target/i386/cpu.c:cpu_x86_cpuid() case 0x8000001F:
>>
>> case 0x8000001F:
>> *eax = *ebx = *ecx = *edx = 0;
>> if (sev_enabled()) {
>> *eax = 0x2;
>> *eax |= sev_es_enabled() ? 0x8 : 0;
>> *eax |= sev_snp_enabled() ? 0x10 : 0;
>> *ebx = sev_get_cbit_position() & 0x3f; /* EBX[5:0] */
>> *ebx |= (sev_get_reduced_phys_bits() & 0x3f) << 6; /* EBX[11:6] */
>> }
>> break;
>>
>> sev_enabled() verifies if the QOM object is TYPE_SEV_GUEST;
>> TYPE_SEV_EMULATED is derived from TYPE_SEV_GUEST with SevEmulatedState
>> to satisfy this check with minimal changes. In particular this allows
>> to bypass all the sev_enabled() checks for future features.
>>
>> Since KVM hardware isn't available, override the QOM's kvm_init() and add
>> a conditional confidential_guest_kvm_init() call during machine_init() to
>> set up emulated confidential support using the ConfidentialGuestSupport
>> structure.
>>
>> 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
>>
>> To the QEMU start arguments.
>>
>> Signed-off-by: Tommaso Califano <[email protected]>
>
> [...]
>
>> 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.
>
> Wrap the paragraph, please:
>
> # Properties for sev-emulated objects. This object functionally
> # emulates AMD SEV hardware via TCG, so it does not require real
> # hardware to run.
>
I'll do it.
>> +#
>> +# Since: 10.1.0
>
> 11.0 right now, but realistically 11.1.
>
I'll update it to 11.1.
>> +##
>> +{ 'struct': 'SevEmulatedProperties',
>> + 'base': 'SevGuestProperties',
>> + 'data': {}}
>> +
>> ##
>> # @SevSnpGuestProperties:
>> #
>> @@ -1241,6 +1254,7 @@
>> { 'name': 'secret_keyring',
>> 'if': 'CONFIG_SECRET_KEYRING' },
>> 'sev-guest',
>> + 'sev-emulated',
>> 'sev-snp-guest',
>> 'thread-context',
>> 's390-pv-guest',
>
> Please insert before sev-guest to keep things more or less sorted.
>
I'll do it, but I don't understand the convention. I'd organized them
by object derivation hierarchy, so what is the expected sorting order?
>> @@ -1318,6 +1332,7 @@
>> 'secret_keyring': { 'type': 'SecretKeyringProperties',
>> 'if': 'CONFIG_SECRET_KEYRING' },
>> 'sev-guest': 'SevGuestProperties',
>> + 'sev-emulated': 'SevEmulatedProperties',
>
> Likewise.
>
Yes.
>> 'sev-snp-guest': 'SevSnpGuestProperties',
>> 'tdx-guest': 'TdxGuestProperties',
>> 'thread-context': 'ThreadContextProperties',
>
Best regards,
Tommaso Califano
