>-----Original Message----- >From: Daniel P. Berrangé <berra...@redhat.com> >Subject: Re: [PATCH v3 07/21] conf: Add tdx as launch security type > >On Mon, Jun 30, 2025 at 02:17:18PM +0800, Zhenzhong Duan wrote: >> When 'tdx' is used, the VM will be launched with Intel TDX feature enabled. >> TDX feature supports running encrypted VM (Trust Domain, TD) under the >> control of KVM. A TD runs in a CPU model which protects the confidentiality >> of its memory and its CPU state from other software. >> >> There are four optional child elements. Element policy is 64bit hex, bit 0 >> is set to enable TDX debug, bit 28 is set to enable sept-ve-disable, other >> bits are reserved currently. When policy isn't specified, QEMU will use its >> own default value 0x10000000. mrConfigId, mrOwner and mrOwnerConfig >are >> base64 encoded SHA384 digest string. >> >> For example: >> >> <launchSecurity type='tdx'> >> <policy>0x10000001</policy> >> <mrConfigId>xxx</mrConfigId> >> <mrOwner>xxx</mrOwner> >> <mrOwnerConfig>xxx</mrOwnerConfig> >> </launchSecurity> >> >> Signed-off-by: Zhenzhong Duan <zhenzhong.d...@intel.com> >> --- >> src/conf/domain_conf.c | 49 >+++++++++++++++++++++++++++++++ >> src/conf/domain_conf.h | 11 +++++++ >> src/conf/domain_validate.c | 1 + >> src/conf/schemas/domaincommon.rng | 32 ++++++++++++++++++++ >> src/conf/virconftypes.h | 2 ++ >> src/qemu/qemu_cgroup.c | 1 + >> src/qemu/qemu_command.c | 2 ++ >> src/qemu/qemu_driver.c | 1 + >> src/qemu/qemu_firmware.c | 1 + >> src/qemu/qemu_namespace.c | 1 + >> src/qemu/qemu_process.c | 2 ++ >> src/qemu/qemu_validate.c | 1 + >> src/security/security_dac.c | 2 ++ >> 13 files changed, 106 insertions(+) > > >> diff --git a/src/qemu/qemu_firmware.c b/src/qemu/qemu_firmware.c >> index 2d0ec0b4fa..6c65a2751b 100644 >> --- a/src/qemu/qemu_firmware.c >> +++ b/src/qemu/qemu_firmware.c >> @@ -1371,6 +1371,7 @@ qemuFirmwareMatchDomain(const >virDomainDef *def, >> } >> break; >> case VIR_DOMAIN_LAUNCH_SECURITY_PV: >> + case VIR_DOMAIN_LAUNCH_SECURITY_TDX: >> break; >> case VIR_DOMAIN_LAUNCH_SECURITY_NONE: >> case VIR_DOMAIN_LAUNCH_SECURITY_LAST: > >We need a patch in this series that updates qemuFirmwareMatchDomain >to handle TDX guests. > >Currently with > > <os firmware="efi"> > <type arch="x86_64" machine="q35">hvm</type> > <boot dev="hd"/> > </os> > >we are *not* matching the right firmware imagte > >qemuFirmwareMatchDomain:1383 : Firmware >'/usr/share/qemu/firmware/30-edk2-ovmf-4m-qcow2-x64-sb-enrolled.json' >matches domain requirements >qemuFirmwareFillDomainModern:1743 : Found matching firmware >(description path >'/usr/share/qemu/firmware/30-edk2-ovmf-4m-qcow2-x64-sb-enrolled.json') >qemuFirmwareEnableFeaturesModern:1439 : decided on firmware >'/usr/share/edk2/ovmf/OVMF_CODE_4M.secboot.qcow2' template >'/usr/share/edk2/ovmf/OVMF_VARS_4M.secboot.qcow2' >qemuFirmwareEnableFeaturesModern:1473 : Enabling SMM feature >qemuFirmwareEnableFeaturesModern:1476 : Enabling secure loader > >and so we fail to boot as SMM is incompatible with TDX, as >well as incorrectly setting up separate NVRAM. > >The file we should have matched is > > /usr/share/qemu/firmware/60-edk2-ovmf-x64-inteltdx.json > >Which has the right feature for TDX launch security: > > "features": [ > "enrolled-keys", > "intel-tdx", > "secure-boot", > "verbose-dynamic" > ], > >there is already logic in qemu_firmware.c for SEV/SNP, >and the same design pattern should work for TDX too.
Got it, will do. Thanks Zhenzhong
