* [pve-devel] [PATCH edk2-firmware/manager/qemu-server v2 0/7] Add support for Intel TDX
@ 2025-10-01 15:11 Anton Iacobaeus
2025-10-01 15:11 ` [pve-devel] [PATCH edk2-firmware v2 1/3] Change name of SEV-related OVMF files Anton Iacobaeus
` (6 more replies)
0 siblings, 7 replies; 20+ messages in thread
From: Anton Iacobaeus @ 2025-10-01 15:11 UTC (permalink / raw)
To: pve-devel
This patch series adds support for launching Intel TDX confidential VMs
via QEMU. Attestation will be covered in another patch.
Intel TDX requires QEMU >= v10.1 and kernel >= 6.16. A TDX compatible
CPU is also required, with TDX enabled in BIOS.
Thanks to Thomas for the review.
Changes since v1 https://lists.proxmox.com/pipermail/pve-devel/2025-September/075218.html
* Added symlinks to OVMF_CVM_* firmware targets for backward compatibility
* Dropped 4th patch to pve-edk2-firmware, the problem has been resolved by QEMU in v10.1
See https://github.com/intel-staging/qemu-tdx/commit/f77516360fd2a3306fb9b33b268f50cc301913c7
* Reworked error handling for MSR reading
pve-edk2-firmware:
Philipp Giersfeld (3):
Change name of SEV-related OVMF files
Add firmware target for TDFV
Add SCSI in NCCFV for TD guest
.../patches/Enable_SCSI_IntelTdx_DXEFV.patch | 52 ++++++++++++++++
debian/patches/series | 1 +
debian/pve-edk2-firmware-ovmf.install | 7 ++-
debian/pve-edk2-firmware-ovmf.links | 3 +
debian/rules | 59 +++++++++++++------
5 files changed, 100 insertions(+), 22 deletions(-)
create mode 100644 debian/patches/Enable_SCSI_IntelTdx_DXEFV.patch
create mode 100644 debian/pve-edk2-firmware-ovmf.links
pve-manager:
Philipp Giersfeld (1):
Add support for Intel TDX
www/manager6/Makefile | 1 +
www/manager6/qemu/Options.js | 12 +++++
www/manager6/qemu/TdxEdit.js | 90 ++++++++++++++++++++++++++++++++++++
3 files changed, 103 insertions(+)
create mode 100644 www/manager6/qemu/TdxEdit.js
qemu-server:
Philipp Giersfeld (3):
Adapt AMD SEV code for compatibility with other platforms
Add check for TDX support
Add support for Intel TDX
src/PVE/API2/Qemu.pm | 6 +-
src/PVE/QemuMigrate/Helpers.pm | 1 +
src/PVE/QemuServer.pm | 27 +++++-
src/PVE/QemuServer/CPUConfig.pm | 46 +++++++--
src/PVE/QemuServer/OVMF.pm | 51 ++++++----
.../query-machine-capabilities.c | 97 ++++++++++++++++---
src/test/cfg2cmd/sev-es.conf.cmd | 2 +-
src/test/cfg2cmd/sev-snp.conf.cmd | 2 +-
src/test/cfg2cmd/sev-std.conf.cmd | 2 +-
src/usr/modules-load.conf | 1 +
10 files changed, 184 insertions(+), 51 deletions(-)
--
2.43.0
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* [pve-devel] [PATCH edk2-firmware v2 1/3] Change name of SEV-related OVMF files 2025-10-01 15:11 [pve-devel] [PATCH edk2-firmware/manager/qemu-server v2 0/7] Add support for Intel TDX Anton Iacobaeus @ 2025-10-01 15:11 ` Anton Iacobaeus 2025-10-07 15:24 ` Fiona Ebner 2025-10-01 15:11 ` [pve-devel] [PATCH edk2-firmware v2 2/3] Add firmware target for TDFV Anton Iacobaeus ` (5 subsequent siblings) 6 siblings, 1 reply; 20+ messages in thread From: Anton Iacobaeus @ 2025-10-01 15:11 UTC (permalink / raw) To: pve-devel; +Cc: Philipp Giersfeld From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> Change variables names to seperate OVMF files from other platforms, such as Intel TDX. Add symlinks for backward compatibility with qemu-server. Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> Signed-off-by: Anton Iacobaeus <anton.iacobaeus@canarybit.eu> --- debian/pve-edk2-firmware-ovmf.install | 6 ++-- debian/pve-edk2-firmware-ovmf.links | 3 ++ debian/rules | 40 ++++++++++++++------------- 3 files changed, 27 insertions(+), 22 deletions(-) create mode 100644 debian/pve-edk2-firmware-ovmf.links diff --git a/debian/pve-edk2-firmware-ovmf.install b/debian/pve-edk2-firmware-ovmf.install index a51846e..981ac27 100644 --- a/debian/pve-edk2-firmware-ovmf.install +++ b/debian/pve-edk2-firmware-ovmf.install @@ -1,8 +1,8 @@ debian/ovmf-install/OVMF_CODE*.fd /usr/share/pve-edk2-firmware debian/ovmf-install/OVMF_VARS*.fd /usr/share/pve-edk2-firmware -debian/ovmf-cvm-install/OVMF_CVM_CODE*.fd /usr/share/pve-edk2-firmware -debian/ovmf-cvm-install/OVMF_CVM_VARS*.fd /usr/share/pve-edk2-firmware -debian/ovmf-cvm-install/OVMF_CVM_4M.fd /usr/share/pve-edk2-firmware +debian/ovmf-sev-install/OVMF_SEV_CODE*.fd /usr/share/pve-edk2-firmware +debian/ovmf-sev-install/OVMF_SEV_VARS*.fd /usr/share/pve-edk2-firmware +debian/ovmf-sev-install/OVMF_SEV_4M.fd /usr/share/pve-edk2-firmware debian/ovmf32-install/OVMF32_CODE*.fd /usr/share/pve-edk2-firmware debian/ovmf32-install/OVMF32_VARS*.fd /usr/share/pve-edk2-firmware debian/PkKek-1-snakeoil.* /usr/share/pve-edk2-firmware diff --git a/debian/pve-edk2-firmware-ovmf.links b/debian/pve-edk2-firmware-ovmf.links new file mode 100644 index 0000000..3ffca93 --- /dev/null +++ b/debian/pve-edk2-firmware-ovmf.links @@ -0,0 +1,3 @@ +usr/share/pve-edk2-firmware/OVMF_SEV_CODE_4M.fd usr/share/pve-edk2-firmware/OVMF_CVM_CODE_4M.fd +usr/share/pve-edk2-firmware/OVMF_SEV_VARS_4M.fd usr/share/pve-edk2-firmware/OVMF_CVM_VARS_4M.fd +usr/share/pve-edk2-firmware/OVMF_SEV_4M.fd usr/share/pve-edk2-firmware/OVMF_CVM_4M.fd diff --git a/debian/rules b/debian/rules index 494f162..dd3bf39 100755 --- a/debian/rules +++ b/debian/rules @@ -37,7 +37,7 @@ OVMF_4M_FLAGS = $(OVMF_COMMON_FLAGS) -DFD_SIZE_4MB OVMF_4M_SMM_FLAGS = $(OVMF_4M_FLAGS) -DSMM_REQUIRE=TRUE OVMF32_4M_FLAGS = $(OVMF_COMMON_FLAGS) -DFD_SIZE_4MB OVMF32_4M_SMM_FLAGS = $(OVMF32_4M_FLAGS) -DSMM_REQUIRE=TRUE -OVMF_CVM_4M_FLAGS = $(OVMF_4M_FLAGS) +OVMF_SEV_4M_FLAGS = $(OVMF_4M_FLAGS) AAVMF_FLAGS = $(COMMON_FLAGS) AAVMF_FLAGS += -DTPM2_ENABLE=TRUE @@ -57,7 +57,7 @@ undefine CONF_PATH %: dh $@ -override_dh_auto_build: build-qemu-efi-aarch64 build-ovmf build-ovmf32 build-ovmf-cvm build-qemu-efi-riscv64 +override_dh_auto_build: build-qemu-efi-aarch64 build-ovmf build-ovmf32 build-ovmf-sev build-qemu-efi-riscv64 debian/setup-build-stamp: cp -a debian/Logo.bmp MdeModulePkg/Logo/Logo.bmp @@ -80,11 +80,13 @@ OVMF32_SHELL = $(OVMF32_BUILD_DIR)/IA32/Shell.efi OVMF32_BINARIES = $(OVMF32_SHELL) OVMF32_IMAGES := $(addprefix $(OVMF32_INSTALL_DIR)/,OVMF32_CODE_4M.secboot.fd OVMF32_VARS_4M.fd) -OVMF_CVM_INSTALL_DIR = debian/ovmf-cvm-install -OVMF_CVM_BUILD_DIR = Build/OvmfX64/$(BUILD_TYPE)_$(EDK2_TOOLCHAIN) -OVMF_CVM_SHELL = $(OVMF_CVM_BUILD_DIR)/X64/Shell.efi -OVMF_CVM_BINARIES = $(OVMF_CVM_SHELL) -OVMF_CVM_IMAGES := $(addprefix $(OVMF_CVM_INSTALL_DIR)/,OVMF_CVM_CODE_4M.fd OVMF_CVM_VARS_4M.fd) +OVMF_SEV_INSTALL_DIR = debian/ovmf-sev-install +OVMF_SEV_BUILD_DIR = Build/OvmfX64/$(BUILD_TYPE)_$(EDK2_TOOLCHAIN) +OVMF_SEV_SHELL = $(OVMF_SEV_BUILD_DIR)/X64/Shell.efi +OVMF_SEV_BINARIES = $(OVMF_SEV_SHELL) +OVMF_SEV_IMAGES := $(addprefix $(OVMF_SEV_INSTALL_DIR)/,OVMF_SEV_CODE_4M.fd OVMF_SEV_VARS_4M.fd OVMF_SEV_4M.fd) +# Note: OVMF_CVM_* are also available via symlinks. Can be removed by next major pve version (PVE 10). +# See pve-edk2-firmware-ovmf.links QEMU_EFI_BUILD_DIR = Build/ArmVirtQemu-$(EDK2_HOST_ARCH)/$(BUILD_TYPE)_$(EDK2_TOOLCHAIN) AAVMF_BUILD_DIR = Build/ArmVirtQemu-AARCH64/$(BUILD_TYPE)_$(EDK2_TOOLCHAIN) @@ -113,22 +115,22 @@ $(OVMF32_BINARIES) $(OVMF32_IMAGES): debian/setup-build-stamp cp $(OVMF32_BUILD_DIR)/FV/OVMF_VARS.fd \ $(OVMF32_INSTALL_DIR)/OVMF32_VARS_4M.fd -build-ovmf-cvm: $(OVMF_CVM_BINARIES) $(OVMF_CVM_IMAGES) -$(OVMF_CVM_BINARIES) $(OVMF_CVM_IMAGES): debian/setup-build-stamp - rm -rf $(OVMF_CVM_INSTALL_DIR) - mkdir $(OVMF_CVM_INSTALL_DIR) +build-ovmf-sev: $(OVMF_SEV_BINARIES) $(OVMF_SEV_IMAGES) +$(OVMF_SEV_BINARIES) $(OVMF_SEV_IMAGES): debian/setup-build-stamp + rm -rf $(OVMF_SEV_INSTALL_DIR) + mkdir $(OVMF_SEV_INSTALL_DIR) set -e; . ./edksetup.sh; \ build -a X64 \ -t $(EDK2_TOOLCHAIN) \ -p OvmfPkg/OvmfPkgX64.dsc \ - $(OVMF_CVM_4M_FLAGS) -b $(BUILD_TYPE) + $(OVMF_SEV_4M_FLAGS) -b $(BUILD_TYPE) #-b $(BUILD_TYPE) - cp $(OVMF_CVM_BUILD_DIR)/FV/OVMF_CODE.fd \ - $(OVMF_CVM_INSTALL_DIR)/OVMF_CVM_CODE_4M.fd - cp $(OVMF_CVM_BUILD_DIR)/FV/OVMF_VARS.fd \ - $(OVMF_CVM_INSTALL_DIR)/OVMF_CVM_VARS_4M.fd - cp $(OVMF_CVM_BUILD_DIR)/FV/OVMF.fd \ - $(OVMF_CVM_INSTALL_DIR)/OVMF_CVM_4M.fd + cp $(OVMF_SEV_BUILD_DIR)/FV/OVMF_CODE.fd \ + $(OVMF_SEV_INSTALL_DIR)/OVMF_SEV_CODE_4M.fd + cp $(OVMF_SEV_BUILD_DIR)/FV/OVMF_VARS.fd \ + $(OVMF_SEV_INSTALL_DIR)/OVMF_SEV_VARS_4M.fd + cp $(OVMF_SEV_BUILD_DIR)/FV/OVMF.fd \ + $(OVMF_SEV_INSTALL_DIR)/OVMF_SEV_4M.fd build-ovmf: $(OVMF_BINARIES) $(OVMF_IMAGES) $(OVMF_PREENROLLED_VARS) $(OVMF_BINARIES) $(OVMF_IMAGES): debian/setup-build-stamp @@ -274,4 +276,4 @@ get-orig-source: edk2-$(DEB_VERSION_UPSTREAM) rm -rf edk2.tmp edk2-$(DEB_VERSION_UPSTREAM) -.PHONY: build-ovmf build-ovmf32 build-ovmf-cvm build-qemu-efi build-qemu-efi-aarch64 build-qemu-efi-riscv64 +.PHONY: build-ovmf build-ovmf32 build-ovmf-sev build-qemu-efi build-qemu-efi-aarch64 build-qemu-efi-riscv64 -- 2.43.0 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [pve-devel] [PATCH edk2-firmware v2 1/3] Change name of SEV-related OVMF files 2025-10-01 15:11 ` [pve-devel] [PATCH edk2-firmware v2 1/3] Change name of SEV-related OVMF files Anton Iacobaeus @ 2025-10-07 15:24 ` Fiona Ebner 0 siblings, 0 replies; 20+ messages in thread From: Fiona Ebner @ 2025-10-07 15:24 UTC (permalink / raw) To: Proxmox VE development discussion, Anton Iacobaeus; +Cc: Philipp Giersfeld Am 04.10.25 um 3:23 PM schrieb Anton Iacobaeus: > From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> > > Change variables names to seperate OVMF files from other platforms, such > as Intel TDX. > > Add symlinks for backward compatibility with qemu-server. > > Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> > Signed-off-by: Anton Iacobaeus <anton.iacobaeus@canarybit.eu> Reviewed-by: Fiona Ebner <f.ebner@proxmox.com> > @@ -80,11 +80,13 @@ OVMF32_SHELL = $(OVMF32_BUILD_DIR)/IA32/Shell.efi > OVMF32_BINARIES = $(OVMF32_SHELL) > OVMF32_IMAGES := $(addprefix $(OVMF32_INSTALL_DIR)/,OVMF32_CODE_4M.secboot.fd OVMF32_VARS_4M.fd) > > -OVMF_CVM_INSTALL_DIR = debian/ovmf-cvm-install > -OVMF_CVM_BUILD_DIR = Build/OvmfX64/$(BUILD_TYPE)_$(EDK2_TOOLCHAIN) > -OVMF_CVM_SHELL = $(OVMF_CVM_BUILD_DIR)/X64/Shell.efi > -OVMF_CVM_BINARIES = $(OVMF_CVM_SHELL) > -OVMF_CVM_IMAGES := $(addprefix $(OVMF_CVM_INSTALL_DIR)/,OVMF_CVM_CODE_4M.fd OVMF_CVM_VARS_4M.fd) > +OVMF_SEV_INSTALL_DIR = debian/ovmf-sev-install > +OVMF_SEV_BUILD_DIR = Build/OvmfX64/$(BUILD_TYPE)_$(EDK2_TOOLCHAIN) > +OVMF_SEV_SHELL = $(OVMF_SEV_BUILD_DIR)/X64/Shell.efi > +OVMF_SEV_BINARIES = $(OVMF_SEV_SHELL) > +OVMF_SEV_IMAGES := $(addprefix $(OVMF_SEV_INSTALL_DIR)/,OVMF_SEV_CODE_4M.fd OVMF_SEV_VARS_4M.fd OVMF_SEV_4M.fd) Just one nit: adding the "OVMF_SEV_4M.fd" to the list could've been a separate commit or mentioned in the commit message, but no big deal :) _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* [pve-devel] [PATCH edk2-firmware v2 2/3] Add firmware target for TDFV 2025-10-01 15:11 [pve-devel] [PATCH edk2-firmware/manager/qemu-server v2 0/7] Add support for Intel TDX Anton Iacobaeus 2025-10-01 15:11 ` [pve-devel] [PATCH edk2-firmware v2 1/3] Change name of SEV-related OVMF files Anton Iacobaeus @ 2025-10-01 15:11 ` Anton Iacobaeus 2025-10-07 15:24 ` Fiona Ebner 2025-10-01 15:11 ` [pve-devel] [PATCH edk2-firmware v2 3/3] Add SCSI in NCCFV for TD guest Anton Iacobaeus ` (4 subsequent siblings) 6 siblings, 1 reply; 20+ messages in thread From: Anton Iacobaeus @ 2025-10-01 15:11 UTC (permalink / raw) To: pve-devel; +Cc: Philipp Giersfeld From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> TDVF enables UEFI support for TDX virtual machines. Add a build target to build TDFV in Config-B (https://github.com/tianocore/edk2/tree/master/OvmfPkg/IntelTdx#configurations-and-features) Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> Signed-off-by: Anton Iacobaeus <anton.iacobaeus@canarybit.eu> --- debian/pve-edk2-firmware-ovmf.install | 1 + debian/rules | 23 +++++++++++++++++++++-- 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/debian/pve-edk2-firmware-ovmf.install b/debian/pve-edk2-firmware-ovmf.install index 981ac27..2218656 100644 --- a/debian/pve-edk2-firmware-ovmf.install +++ b/debian/pve-edk2-firmware-ovmf.install @@ -3,6 +3,7 @@ debian/ovmf-install/OVMF_VARS*.fd /usr/share/pve-edk2-firmware debian/ovmf-sev-install/OVMF_SEV_CODE*.fd /usr/share/pve-edk2-firmware debian/ovmf-sev-install/OVMF_SEV_VARS*.fd /usr/share/pve-edk2-firmware debian/ovmf-sev-install/OVMF_SEV_4M.fd /usr/share/pve-edk2-firmware +debian/ovmf-tdx-install/OVMF_TDX_4M.fd /usr/share/pve-edk2-firmware debian/ovmf32-install/OVMF32_CODE*.fd /usr/share/pve-edk2-firmware debian/ovmf32-install/OVMF32_VARS*.fd /usr/share/pve-edk2-firmware debian/PkKek-1-snakeoil.* /usr/share/pve-edk2-firmware diff --git a/debian/rules b/debian/rules index dd3bf39..5850370 100755 --- a/debian/rules +++ b/debian/rules @@ -38,6 +38,7 @@ OVMF_4M_SMM_FLAGS = $(OVMF_4M_FLAGS) -DSMM_REQUIRE=TRUE OVMF32_4M_FLAGS = $(OVMF_COMMON_FLAGS) -DFD_SIZE_4MB OVMF32_4M_SMM_FLAGS = $(OVMF32_4M_FLAGS) -DSMM_REQUIRE=TRUE OVMF_SEV_4M_FLAGS = $(OVMF_4M_FLAGS) +OVMF_TDX_4M_FLAGS = $(OVMF_4M_FLAGS) AAVMF_FLAGS = $(COMMON_FLAGS) AAVMF_FLAGS += -DTPM2_ENABLE=TRUE @@ -57,7 +58,7 @@ undefine CONF_PATH %: dh $@ -override_dh_auto_build: build-qemu-efi-aarch64 build-ovmf build-ovmf32 build-ovmf-sev build-qemu-efi-riscv64 +override_dh_auto_build: build-qemu-efi-aarch64 build-ovmf build-ovmf32 build-ovmf-sev build-ovmf-tdx build-qemu-efi-riscv64 debian/setup-build-stamp: cp -a debian/Logo.bmp MdeModulePkg/Logo/Logo.bmp @@ -88,6 +89,12 @@ OVMF_SEV_IMAGES := $(addprefix $(OVMF_SEV_INSTALL_DIR)/,OVMF_SEV_CODE_4M.fd OVM # Note: OVMF_CVM_* are also available via symlinks. Can be removed by next major pve version (PVE 10). # See pve-edk2-firmware-ovmf.links +OVMF_TDX_INSTALL_DIR = debian/ovmf-tdx-install +OVMF_TDX_BUILD_DIR = Build/IntelTdx/$(BUILD_TYPE)_$(EDK2_TOOLCHAIN) +OVMF_TDX_SHELL = $(OVMF_TDX_BUILD_DIR)/X64/Shell.efi +OVMF_TDX_BINARIES = $(OVMF_TDX_SHELL) +OVMF_TDX_IMAGES := $(addprefix $(OVMF_TDX_INSTALL_DIR)/,OVMF_TDX_4M.fd) + QEMU_EFI_BUILD_DIR = Build/ArmVirtQemu-$(EDK2_HOST_ARCH)/$(BUILD_TYPE)_$(EDK2_TOOLCHAIN) AAVMF_BUILD_DIR = Build/ArmVirtQemu-AARCH64/$(BUILD_TYPE)_$(EDK2_TOOLCHAIN) AAVMF_ENROLL = $(AAVMF_BUILD_DIR)/AARCH64/EnrollDefaultKeys.efi @@ -132,6 +139,18 @@ $(OVMF_SEV_BINARIES) $(OVMF_SEV_IMAGES): debian/setup-build-stamp cp $(OVMF_SEV_BUILD_DIR)/FV/OVMF.fd \ $(OVMF_SEV_INSTALL_DIR)/OVMF_SEV_4M.fd +build-ovmf-tdx: $(OVMF_TDX_BINARIES) $(OVMF_TDX_IMAGES) +$(OVMF_TDX_BINARIES) $(OVMF_TDX_IMAGES): debian/setup-build-stamp + rm -rf $(OVMF_TDX_INSTALL_DIR) + mkdir $(OVMF_TDX_INSTALL_DIR) + set -e; . ./edksetup.sh; \ + build -a X64 \ + -t $(EDK2_TOOLCHAIN) \ + -p OvmfPkg/IntelTdx/IntelTdxX64.dsc \ + $(OVMF_TDX_4M_FLAGS) -b $(BUILD_TYPE) + cp $(OVMF_TDX_BUILD_DIR)/FV/OVMF.fd \ + $(OVMF_TDX_INSTALL_DIR)/OVMF_TDX_4M.fd + build-ovmf: $(OVMF_BINARIES) $(OVMF_IMAGES) $(OVMF_PREENROLLED_VARS) $(OVMF_BINARIES) $(OVMF_IMAGES): debian/setup-build-stamp rm -rf $(OVMF_INSTALL_DIR) @@ -276,4 +295,4 @@ get-orig-source: edk2-$(DEB_VERSION_UPSTREAM) rm -rf edk2.tmp edk2-$(DEB_VERSION_UPSTREAM) -.PHONY: build-ovmf build-ovmf32 build-ovmf-sev build-qemu-efi build-qemu-efi-aarch64 build-qemu-efi-riscv64 +.PHONY: build-ovmf build-ovmf32 build-ovmf-sev build-ovmf-tdx build-qemu-efi build-qemu-efi-aarch64 build-qemu-efi-riscv64 -- 2.43.0 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [pve-devel] [PATCH edk2-firmware v2 2/3] Add firmware target for TDFV 2025-10-01 15:11 ` [pve-devel] [PATCH edk2-firmware v2 2/3] Add firmware target for TDFV Anton Iacobaeus @ 2025-10-07 15:24 ` Fiona Ebner 2025-10-13 14:02 ` Anton Iacobaeus 0 siblings, 1 reply; 20+ messages in thread From: Fiona Ebner @ 2025-10-07 15:24 UTC (permalink / raw) To: Proxmox VE development discussion, Anton Iacobaeus; +Cc: Philipp Giersfeld Am 04.10.25 um 3:23 PM schrieb Anton Iacobaeus: > From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> > > TDVF enables UEFI support for TDX virtual machines. Add a build target > to build TDFV in Config-B (https://github.com/tianocore/edk2/tree/master/OvmfPkg/IntelTdx#configurations-and-features) Would be great to have a 1-2 sentences for the rationale why this variant was chosen in the commit message. I suppose because the other one isn't fully featured? > Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> > Signed-off-by: Anton Iacobaeus <anton.iacobaeus@canarybit.eu> Reviewed-by: Fiona Ebner <f.ebner@proxmox.com> _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [pve-devel] [PATCH edk2-firmware v2 2/3] Add firmware target for TDFV 2025-10-07 15:24 ` Fiona Ebner @ 2025-10-13 14:02 ` Anton Iacobaeus 0 siblings, 0 replies; 20+ messages in thread From: Anton Iacobaeus @ 2025-10-13 14:02 UTC (permalink / raw) To: Fiona Ebner, Proxmox VE development discussion; +Cc: Philipp Giersfeld On 10/7/25 17:24, Fiona Ebner wrote: > Am 04.10.25 um 3:23 PM schrieb Anton Iacobaeus: >> From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> >> >> TDVF enables UEFI support for TDX virtual machines. Add a build target >> to build TDFV in Config-B (https://github.com/tianocore/edk2/tree/master/OvmfPkg/IntelTdx#configurations-and-features) > > Would be great to have a 1-2 sentences for the rationale why this > variant was chosen in the commit message. I suppose because the other > one isn't fully featured? > >> Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> >> Signed-off-by: Anton Iacobaeus <anton.iacobaeus@canarybit.eu> > > Reviewed-by: Fiona Ebner <f.ebner@proxmox.com> > That is exactly right, I will add some details to the commit message. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* [pve-devel] [PATCH edk2-firmware v2 3/3] Add SCSI in NCCFV for TD guest 2025-10-01 15:11 [pve-devel] [PATCH edk2-firmware/manager/qemu-server v2 0/7] Add support for Intel TDX Anton Iacobaeus 2025-10-01 15:11 ` [pve-devel] [PATCH edk2-firmware v2 1/3] Change name of SEV-related OVMF files Anton Iacobaeus 2025-10-01 15:11 ` [pve-devel] [PATCH edk2-firmware v2 2/3] Add firmware target for TDFV Anton Iacobaeus @ 2025-10-01 15:11 ` Anton Iacobaeus 2025-10-07 15:24 ` Fiona Ebner 2025-10-01 15:11 ` [pve-devel] [PATCH manager v2 1/1] Add support for Intel TDX Anton Iacobaeus ` (3 subsequent siblings) 6 siblings, 1 reply; 20+ messages in thread From: Anton Iacobaeus @ 2025-10-01 15:11 UTC (permalink / raw) To: pve-devel; +Cc: Philipp Giersfeld From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> The FV in `IntelTdx/IntelTdxX64.fdf` was split into two FVs, one for a TD guest and one for non-cc guest. The SCSI driver was moved to the non-cc NCCFV. In order for PVE to use an image with SCSI include the SCSI driver in the FV for TD guest. Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> Signed-off-by: Anton Iacobaeus <anton.iacobaeus@canarybit.eu> --- .../patches/Enable_SCSI_IntelTdx_DXEFV.patch | 52 +++++++++++++++++++ debian/patches/series | 1 + 2 files changed, 53 insertions(+) create mode 100644 debian/patches/Enable_SCSI_IntelTdx_DXEFV.patch diff --git a/debian/patches/Enable_SCSI_IntelTdx_DXEFV.patch b/debian/patches/Enable_SCSI_IntelTdx_DXEFV.patch new file mode 100644 index 0000000..5f9c40d --- /dev/null +++ b/debian/patches/Enable_SCSI_IntelTdx_DXEFV.patch @@ -0,0 +1,52 @@ +diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.fdf b/OvmfPkg/IntelTdx/IntelTdxX64.fdf +index c05761ab..02807c37 100644 +--- a/OvmfPkg/IntelTdx/IntelTdxX64.fdf ++++ b/OvmfPkg/IntelTdx/IntelTdxX64.fdf +@@ -204,6 +204,16 @@ INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf + INF OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf + INF OvmfPkg/Virtio10Dxe/Virtio10.inf + INF OvmfPkg/VirtioBlkDxe/VirtioBlk.inf ++INF OvmfPkg/VirtioScsiDxe/VirtioScsi.inf ++!if $(PVSCSI_ENABLE) == TRUE ++INF OvmfPkg/PvScsiDxe/PvScsiDxe.inf ++!endif ++!if $(MPT_SCSI_ENABLE) == TRUE ++INF OvmfPkg/MptScsiDxe/MptScsiDxe.inf ++!endif ++!if $(LSI_SCSI_ENABLE) == TRUE ++INF OvmfPkg/LsiScsiDxe/LsiScsiDxe.inf ++!endif + + !if $(SECURE_BOOT_ENABLE) == TRUE + INF SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf +@@ -223,6 +233,8 @@ INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf + INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf + INF MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf + INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf ++INF MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf ++INF MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf + INF MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf + INF MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf + INF MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf +@@ -290,21 +302,9 @@ READ_LOCK_STATUS = TRUE + # DXE Phase modules + # + INF MdeModulePkg/Universal/EbcDxe/EbcDxe.inf +-INF OvmfPkg/VirtioScsiDxe/VirtioScsi.inf +-!if $(PVSCSI_ENABLE) == TRUE +-INF OvmfPkg/PvScsiDxe/PvScsiDxe.inf +-!endif +-!if $(MPT_SCSI_ENABLE) == TRUE +-INF OvmfPkg/MptScsiDxe/MptScsiDxe.inf +-!endif +-!if $(LSI_SCSI_ENABLE) == TRUE +-INF OvmfPkg/LsiScsiDxe/LsiScsiDxe.inf +-!endif + INF MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf + INF MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf + INF MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf +-INF MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf +-INF MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf + INF MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf + INF MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf + INF MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf diff --git a/debian/patches/series b/debian/patches/series index f9e3582..c0155a2 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -5,3 +5,4 @@ Revert-ArmVirtPkg-make-EFI_LOADER_DATA-non-executabl.patch ArmVirtPkg-disable-the-EFI_MEMORY_ATTRIBUTE-protocol.patch Revert-UefiCpuPkg-Produce-EFI-memory-attributes-prot.patch UefiCpuPkg-MpInitLib-Fix-split-lock-violation-from-M.patch +Enable_SCSI_IntelTdx_DXEFV.patch -- 2.43.0 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [pve-devel] [PATCH edk2-firmware v2 3/3] Add SCSI in NCCFV for TD guest 2025-10-01 15:11 ` [pve-devel] [PATCH edk2-firmware v2 3/3] Add SCSI in NCCFV for TD guest Anton Iacobaeus @ 2025-10-07 15:24 ` Fiona Ebner 2025-10-13 14:02 ` Anton Iacobaeus 0 siblings, 1 reply; 20+ messages in thread From: Fiona Ebner @ 2025-10-07 15:24 UTC (permalink / raw) To: Proxmox VE development discussion, Anton Iacobaeus; +Cc: Philipp Giersfeld Am 04.10.25 um 3:23 PM schrieb Anton Iacobaeus: > From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> > > The FV in `IntelTdx/IntelTdxX64.fdf` was split into two FVs, one for a > TD guest and one for non-cc guest. The SCSI driver was moved to the > non-cc NCCFV. In order for PVE to use an image with SCSI include the > SCSI driver in the FV for TD guest. Did you already ask upstream whether they would be willing to include SCSI for the TD guest or is there no interest? Some of it is already guarded via _ENABLE flags anyways. I'm fine with going with this, but it's always nice to have no more diff than necessary to upstream. > Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> > Signed-off-by: Anton Iacobaeus <anton.iacobaeus@canarybit.eu> Reviewed-by: Fiona Ebner <f.ebner@proxmox.com> Unfortunately, mailman ate the special line endings in the diff below, so it's necessary to fix them up locally to be able to build the package. Should there be another version of the series, please use --transfer-encoding=base64 when sending the message with git. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [pve-devel] [PATCH edk2-firmware v2 3/3] Add SCSI in NCCFV for TD guest 2025-10-07 15:24 ` Fiona Ebner @ 2025-10-13 14:02 ` Anton Iacobaeus 2025-10-14 7:50 ` Fiona Ebner 0 siblings, 1 reply; 20+ messages in thread From: Anton Iacobaeus @ 2025-10-13 14:02 UTC (permalink / raw) To: Fiona Ebner, Proxmox VE development discussion; +Cc: Philipp Giersfeld On 10/7/25 17:24, Fiona Ebner wrote: > Am 04.10.25 um 3:23 PM schrieb Anton Iacobaeus: >> From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> >> >> The FV in `IntelTdx/IntelTdxX64.fdf` was split into two FVs, one for a >> TD guest and one for non-cc guest. The SCSI driver was moved to the >> non-cc NCCFV. In order for PVE to use an image with SCSI include the >> SCSI driver in the FV for TD guest. > > Did you already ask upstream whether they would be willing to include > SCSI for the TD guest or is there no interest? Some of it is already > guarded via _ENABLE flags anyways. I'm fine with going with this, but > it's always nice to have no more diff than necessary to upstream. > We asked upstream and they said that there is no architecture issue with the SCSI driver, but it is a matter of validation. As of now there are no plans to include it, but an official request for it could be made. The process will likely be lengthy however and they also mentioned that including the driver manually is a good option. >> Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> >> Signed-off-by: Anton Iacobaeus <anton.iacobaeus@canarybit.eu> > > Reviewed-by: Fiona Ebner <f.ebner@proxmox.com> > > Unfortunately, mailman ate the special line endings in the diff below, > so it's necessary to fix them up locally to be able to build the > package. Should there be another version of the series, please use > --transfer-encoding=base64 when sending the message with git. > Thank you for the review! I will clean up some things and make a v3. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [pve-devel] [PATCH edk2-firmware v2 3/3] Add SCSI in NCCFV for TD guest 2025-10-13 14:02 ` Anton Iacobaeus @ 2025-10-14 7:50 ` Fiona Ebner 0 siblings, 0 replies; 20+ messages in thread From: Fiona Ebner @ 2025-10-14 7:50 UTC (permalink / raw) To: Anton Iacobaeus, Proxmox VE development discussion; +Cc: Philipp Giersfeld Am 13.10.25 um 4:01 PM schrieb Anton Iacobaeus: > On 10/7/25 17:24, Fiona Ebner wrote: >> Am 04.10.25 um 3:23 PM schrieb Anton Iacobaeus: >>> From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> >>> >>> The FV in `IntelTdx/IntelTdxX64.fdf` was split into two FVs, one for a >>> TD guest and one for non-cc guest. The SCSI driver was moved to the >>> non-cc NCCFV. In order for PVE to use an image with SCSI include the >>> SCSI driver in the FV for TD guest. >> >> Did you already ask upstream whether they would be willing to include >> SCSI for the TD guest or is there no interest? Some of it is already >> guarded via _ENABLE flags anyways. I'm fine with going with this, but >> it's always nice to have no more diff than necessary to upstream. >> > > We asked upstream and they said that there is no architecture issue with > the SCSI driver, but it is a matter of validation. As of now there are > no plans to include it, but an official request for it could be made. > The process will likely be lengthy however and they also mentioned that > including the driver manually is a good option. Good to know! The patch is rather straight-forward, so let's just go with including it manually. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* [pve-devel] [PATCH manager v2 1/1] Add support for Intel TDX 2025-10-01 15:11 [pve-devel] [PATCH edk2-firmware/manager/qemu-server v2 0/7] Add support for Intel TDX Anton Iacobaeus ` (2 preceding siblings ...) 2025-10-01 15:11 ` [pve-devel] [PATCH edk2-firmware v2 3/3] Add SCSI in NCCFV for TD guest Anton Iacobaeus @ 2025-10-01 15:11 ` Anton Iacobaeus 2025-10-01 15:11 ` [pve-devel] [PATCH qemu-server v2 1/3] Adapt AMD SEV code for compatibility with other platforms Anton Iacobaeus ` (2 subsequent siblings) 6 siblings, 0 replies; 20+ messages in thread From: Anton Iacobaeus @ 2025-10-01 15:11 UTC (permalink / raw) To: pve-devel; +Cc: Philipp Giersfeld From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> This commit adds suppport to enable Intel TDX for a VM similar to AMD SEV. Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> Signed-off-by: Anton Iacobaeus <anton.iacobaeus@canarybit.eu> --- www/manager6/Makefile | 1 + www/manager6/qemu/Options.js | 12 +++++ www/manager6/qemu/TdxEdit.js | 90 ++++++++++++++++++++++++++++++++++++ 3 files changed, 103 insertions(+) create mode 100644 www/manager6/qemu/TdxEdit.js diff --git a/www/manager6/Makefile b/www/manager6/Makefile index 07401f21..5a79eed7 100644 --- a/www/manager6/Makefile +++ b/www/manager6/Makefile @@ -275,6 +275,7 @@ JSSRC= \ qemu/SevEdit.js \ qemu/Smbios1Edit.js \ qemu/SystemEdit.js \ + qemu/TdxEdit.js \ qemu/USBEdit.js \ qemu/VirtiofsEdit.js \ sdn/Browser.js \ diff --git a/www/manager6/qemu/Options.js b/www/manager6/qemu/Options.js index 6fe96fe2..044ed227 100644 --- a/www/manager6/qemu/Options.js +++ b/www/manager6/qemu/Options.js @@ -386,6 +386,18 @@ Ext.define('PVE.qemu.Options', { return value; }, }, + 'intel-tdx': { + header: gettext('Intel TDX'), + editor: caps.vms['VM.Config.HWType'] ? 'PVE.qemu.TdxEdit' : undefined, + defaultValue: Proxmox.Utils.defaultText + ' (' + Proxmox.Utils.disabledText + ')', + renderer: function(value, metaData, record, ri, ci, store, pending) { + let intel_tdx = PVE.Parser.parsePropertyString(value, "type"); + if (intel_tdx.type === 'tdx') { + return 'Intel (' + value + ')'; + } + return value; + }, + }, hookscript: { header: gettext('Hookscript'), }, diff --git a/www/manager6/qemu/TdxEdit.js b/www/manager6/qemu/TdxEdit.js new file mode 100644 index 00000000..735a478c --- /dev/null +++ b/www/manager6/qemu/TdxEdit.js @@ -0,0 +1,90 @@ +Ext.define('PVE.qemu.TdxInputPanel', { + extend: 'Proxmox.panel.InputPanel', + xtype: 'pveTdxInputPanel', + + onlineHelp: 'qm_memory', // TODO: change to 'qm_memory_encryption' one available + + viewModel: { + data: { + type: '__default__', + }, + formulas: { + tdxEnabled: get => get('type') === 'tdx', + }, + }, + + onGetValues: function(values) { + if (values.delete === 'type') { + values.delete = 'intel-tdx'; + return values; + } + let ret = {}; + ret['intel-tdx'] = PVE.Parser.printPropertyString(values, 'type'); + return ret; + }, + + + setValues: function(values) { + this.callParent(arguments); + }, + + items: [{ + xtype: 'proxmoxKVComboBox', + fieldLabel: gettext('Intel TDX Type'), + labelWidth: 150, + name: 'type', + value: '__default__', + comboItems: [ + ['__default__', Proxmox.Utils.defaultText + ' (' + Proxmox.Utils.disabledText + ')'], + ['tdx', 'Intel TDX'], + ], + bind: { + value: '{type}', + }, + }, + { + xtype: 'displayfield', + userCls: 'pmx-hint', + value: gettext('WARNING: When using Intel TDX no EFI disk is loaded as pflash.'), + bind: { + hidden: '{!tdxEnabled}', + }, + }, + { + xtype: 'displayfield', + userCls: 'pmx-hint', + value: gettext('Note: Intel TDX requires host kernel version 6.16 or higher.'), + bind: { + hidden: '{!tdxEnabled}', + }, + }], + + advancedItems: [ + ], +}); + +Ext.define('PVE.qemu.TdxEdit', { + extend: 'Proxmox.window.Edit', + + subject: 'Intel Trust Domain Extension (TDX)', + + items: { + xtype: 'pveTdxInputPanel', + }, + + width: 400, + + initComponent: function() { + let me = this; + + me.callParent(); + + me.load({ + success: function(response) { + let conf = response.result.data; + let intel_tdx = conf['intel-tdx'] || '__default__'; + me.setValues(PVE.Parser.parsePropertyString(intel_tdx, 'type')); + }, + }); + }, +}); -- 2.43.0 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* [pve-devel] [PATCH qemu-server v2 1/3] Adapt AMD SEV code for compatibility with other platforms 2025-10-01 15:11 [pve-devel] [PATCH edk2-firmware/manager/qemu-server v2 0/7] Add support for Intel TDX Anton Iacobaeus ` (3 preceding siblings ...) 2025-10-01 15:11 ` [pve-devel] [PATCH manager v2 1/1] Add support for Intel TDX Anton Iacobaeus @ 2025-10-01 15:11 ` Anton Iacobaeus 2025-10-07 15:24 ` Fiona Ebner 2025-10-01 15:11 ` [pve-devel] [PATCH qemu-server v2 2/3] Add check for TDX support Anton Iacobaeus 2025-10-01 15:11 ` [pve-devel] [PATCH qemu-server v2 3/3] Add support for Intel TDX Anton Iacobaeus 6 siblings, 1 reply; 20+ messages in thread From: Anton Iacobaeus @ 2025-10-01 15:11 UTC (permalink / raw) To: pve-devel; +Cc: Philipp Giersfeld From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> Change variable and function names that are specific to AMD SEV to reflect this. Also, change name of general CC functions and variable names to be used in conjunction with other platforms. Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> Signed-off-by: Anton Iacobaeus <anton.iacobaeus@canarybit.eu> --- src/PVE/API2/Qemu.pm | 6 ++--- src/PVE/QemuServer.pm | 8 +++---- src/PVE/QemuServer/CPUConfig.pm | 15 ++++++------ src/PVE/QemuServer/OVMF.pm | 40 +++++++++++++++---------------- src/test/cfg2cmd/sev-es.conf.cmd | 2 +- src/test/cfg2cmd/sev-snp.conf.cmd | 2 +- src/test/cfg2cmd/sev-std.conf.cmd | 2 +- 7 files changed, 38 insertions(+), 37 deletions(-) diff --git a/src/PVE/API2/Qemu.pm b/src/PVE/API2/Qemu.pm index 34f615d8..8639065d 100644 --- a/src/PVE/API2/Qemu.pm +++ b/src/PVE/API2/Qemu.pm @@ -618,13 +618,13 @@ my sub create_disks : prototype($$$$$$$$$$$) { if ($ds eq 'efidisk0') { my $smm = PVE::QemuServer::Machine::machine_type_is_q35($conf); - my $amd_sev_type = PVE::QemuServer::CPUConfig::get_amd_sev_type($conf); + my $cvm_type = PVE::QemuServer::CPUConfig::get_cvm_type($conf); die "SEV-SNP uses consolidated read-only firmware and does not require an EFI disk\n" - if $amd_sev_type && $amd_sev_type eq 'snp'; + if $cvm_type && $cvm_type eq 'snp'; ($volid, $size) = PVE::QemuServer::OVMF::create_efidisk( - $storecfg, $storeid, $vmid, $fmt, $arch, $disk, $smm, $amd_sev_type, + $storecfg, $storeid, $vmid, $fmt, $arch, $disk, $smm, $cvm_type, ); } elsif ($ds eq 'tpmstate0') { # swtpm can only use raw volumes, and uses a fixed size diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm index cbcad749..eb2a8c7e 100644 --- a/src/PVE/QemuServer.pm +++ b/src/PVE/QemuServer.pm @@ -61,7 +61,7 @@ use PVE::QemuServer::Helpers use PVE::QemuServer::Cloudinit; use PVE::QemuServer::CGroup; use PVE::QemuServer::CPUConfig - qw(print_cpu_device get_cpu_options get_cpu_bitness is_native_arch get_amd_sev_object get_amd_sev_type); + qw(print_cpu_device get_cpu_options get_cpu_bitness is_native_arch get_amd_sev_object get_cvm_type); use PVE::QemuServer::Drive qw( is_valid_drivename checked_volume_format @@ -3417,7 +3417,7 @@ sub config_to_command { if !$forcecpu && get_cpu_bitness($conf->{cpu}, $arch) == 32; my $hw_info = { - 'amd-sev-type' => get_amd_sev_type($conf), + 'cvm-type' => get_cvm_type($conf), arch => $arch, 'machine-version' => $machine_version, q35 => $q35, @@ -8106,9 +8106,9 @@ sub get_efivars_size { my $arch = PVE::QemuServer::Helpers::get_vm_arch($conf); $efidisk //= $conf->{efidisk0} ? parse_drive('efidisk0', $conf->{efidisk0}) : undef; my $smm = PVE::QemuServer::Machine::machine_type_is_q35($conf); - my $amd_sev_type = get_amd_sev_type($conf); + my $cvm_type = get_cvm_type($conf); - return PVE::QemuServer::OVMF::get_efivars_size($arch, $efidisk, $smm, $amd_sev_type); + return PVE::QemuServer::OVMF::get_efivars_size($arch, $efidisk, $smm, $cvm_type); } sub update_efidisk_size { diff --git a/src/PVE/QemuServer/CPUConfig.pm b/src/PVE/QemuServer/CPUConfig.pm index 786a99d8..65a7b565 100644 --- a/src/PVE/QemuServer/CPUConfig.pm +++ b/src/PVE/QemuServer/CPUConfig.pm @@ -18,7 +18,7 @@ our @EXPORT_OK = qw( get_cpu_bitness is_native_arch get_amd_sev_object - get_amd_sev_type + get_cvm_type ); # under certain race-conditions, this module might be loaded before pve-cluster @@ -881,14 +881,15 @@ sub get_hw_capabilities { return $hw_capabilities; } -sub get_amd_sev_type { +sub get_cvm_type { my ($conf) = @_; - return undef if !$conf->{'amd-sev'}; - - my $sev = PVE::JSONSchema::parse_property_string($sev_fmt, $conf->{'amd-sev'}); - - return $sev->{type}; + if ($conf->{'amd-sev'}) { + my $sev = PVE::JSONSchema::parse_property_string($sev_fmt, $conf->{'amd-sev'}); + return $sev->{type}; + } else { + return undef; + } } sub get_amd_sev_object { diff --git a/src/PVE/QemuServer/OVMF.pm b/src/PVE/QemuServer/OVMF.pm index 08134e30..df44d3f1 100644 --- a/src/PVE/QemuServer/OVMF.pm +++ b/src/PVE/QemuServer/OVMF.pm @@ -29,10 +29,10 @@ my $OVMF = { "$EDK2_FW_BASE/OVMF_CODE_4M.secboot.fd", "$EDK2_FW_BASE/OVMF_VARS_4M.ms.fd", ], '4m-sev' => [ - "$EDK2_FW_BASE/OVMF_CVM_CODE_4M.fd", "$EDK2_FW_BASE/OVMF_CVM_VARS_4M.fd", + "$EDK2_FW_BASE/OVMF_SEV_CODE_4M.fd", "$EDK2_FW_BASE/OVMF_SEV_VARS_4M.fd", ], '4m-snp' => [ - "$EDK2_FW_BASE/OVMF_CVM_4M.fd", + "$EDK2_FW_BASE/OVMF_SEV_4M.fd", ], # FIXME: These are legacy 2MB-sized images that modern OVMF doesn't supports to build # anymore. how can we deperacate this sanely without breaking existing instances, or using @@ -49,19 +49,19 @@ my $OVMF = { }; my sub get_ovmf_files($$$$) { - my ($arch, $efidisk, $smm, $amd_sev_type) = @_; + my ($arch, $efidisk, $smm, $cvm_type) = @_; my $types = $OVMF->{$arch} or die "no OVMF images known for architecture '$arch'\n"; my $type = 'default'; if ($arch eq 'x86_64') { - if ($amd_sev_type && $amd_sev_type eq 'snp') { + if ($cvm_type && $cvm_type eq 'snp') { $type = "4m-snp"; my ($ovmf) = $types->{$type}->@*; die "EFI base image '$ovmf' not found\n" if !-f $ovmf; return ($ovmf); - } elsif ($amd_sev_type) { + } elsif ($cvm_type && ($cvm_type eq 'std' || $cvm_type eq 'es')) { $type = "4m-sev"; } elsif (defined($efidisk->{efitype}) && $efidisk->{efitype} eq '4m') { $type = $smm ? "4m" : "4m-no-smm"; @@ -81,14 +81,14 @@ my sub get_ovmf_files($$$$) { my sub print_ovmf_drive_commandlines { my ($conf, $storecfg, $vmid, $hw_info, $version_guard, $readonly) = @_; - my ($amd_sev_type, $arch, $q35) = $hw_info->@{qw(amd-sev-type arch q35)}; + my ($cvm_type, $arch, $q35) = $hw_info->@{qw(cvm-type arch q35)}; my $d = $conf->{efidisk0} ? parse_drive('efidisk0', $conf->{efidisk0}) : undef; die "Attempting to configure SEV-SNP with pflash devices instead of using `-bios`\n" - if $amd_sev_type && $amd_sev_type eq 'snp'; + if $cvm_type && $cvm_type eq 'snp'; - my ($ovmf_code, $ovmf_vars) = get_ovmf_files($arch, $d, $q35, $amd_sev_type); + my ($ovmf_code, $ovmf_vars) = get_ovmf_files($arch, $d, $q35, $cvm_type); my $var_drive_str = "if=pflash,unit=1,id=drive-efidisk0"; if ($d) { @@ -122,16 +122,16 @@ my sub print_ovmf_drive_commandlines { } sub get_efivars_size { - my ($arch, $efidisk, $smm, $amd_sev_type) = @_; + my ($arch, $efidisk, $smm, $cvm_type) = @_; - my (undef, $ovmf_vars) = get_ovmf_files($arch, $efidisk, $smm, $amd_sev_type); + my (undef, $ovmf_vars) = get_ovmf_files($arch, $efidisk, $smm, $cvm_type); return -s $ovmf_vars; } sub create_efidisk($$$$$$$$) { - my ($storecfg, $storeid, $vmid, $fmt, $arch, $efidisk, $smm, $amd_sev_type) = @_; + my ($storecfg, $storeid, $vmid, $fmt, $arch, $efidisk, $smm, $cvm_type) = @_; - my (undef, $ovmf_vars) = get_ovmf_files($arch, $efidisk, $smm, $amd_sev_type); + my (undef, $ovmf_vars) = get_ovmf_files($arch, $efidisk, $smm, $cvm_type); my $vars_size_b = -s $ovmf_vars; my $vars_size = PVE::Tools::convert_size($vars_size_b, 'b' => 'kb'); @@ -147,15 +147,15 @@ sub create_efidisk($$$$$$$$) { my sub generate_ovmf_blockdev { my ($conf, $storecfg, $vmid, $hw_info, $readonly) = @_; - my ($amd_sev_type, $arch, $machine_version, $q35) = - $hw_info->@{qw(amd-sev-type arch machine-version q35)}; + my ($cvm_type, $arch, $machine_version, $q35) = + $hw_info->@{qw(cvm-type arch machine-version q35)}; my $drive = $conf->{efidisk0} ? parse_drive('efidisk0', $conf->{efidisk0}) : undef; die "Attempting to configure SEV-SNP with pflash devices instead of using `-bios`\n" - if $amd_sev_type && $amd_sev_type eq 'snp'; + if $cvm_type && $cvm_type eq 'snp'; - my ($ovmf_code, $ovmf_vars) = get_ovmf_files($arch, $drive, $q35, $amd_sev_type); + my ($ovmf_code, $ovmf_vars) = get_ovmf_files($arch, $drive, $q35, $cvm_type); my $ovmf_code_blockdev = { driver => 'raw', @@ -203,16 +203,16 @@ my sub generate_ovmf_blockdev { sub print_ovmf_commandline { my ($conf, $storecfg, $vmid, $hw_info, $version_guard, $readonly) = @_; - my $amd_sev_type = $hw_info->{'amd-sev-type'}; + my $cvm_type = $hw_info->{'cvm-type'}; my $cmd = []; my $machine_flags = []; - if ($amd_sev_type && $amd_sev_type eq 'snp') { + if ($cvm_type && $cvm_type eq 'snp') { if (defined($conf->{efidisk0})) { - log_warn("EFI disks are not supported with SEV-SNP and will be ignored"); + log_warn("EFI disks are not supported with Confidential Virtual Machines and will be ignored"); } - push $cmd->@*, '-bios', get_ovmf_files($hw_info->{arch}, undef, undef, $amd_sev_type); + push $cmd->@*, '-bios', get_ovmf_files($hw_info->{arch}, undef, undef, $cvm_type); } else { if ($version_guard->(10, 0, 0)) { # for the switch to -blockdev my ($code_blockdev, $vars_blockdev, $throttle_group) = diff --git a/src/test/cfg2cmd/sev-es.conf.cmd b/src/test/cfg2cmd/sev-es.conf.cmd index 3cc2dbc6..f61a72c6 100644 --- a/src/test/cfg2cmd/sev-es.conf.cmd +++ b/src/test/cfg2cmd/sev-es.conf.cmd @@ -10,7 +10,7 @@ -daemonize \ -smbios 'type=1,uuid=7b10d7af-b932-4c66-b2c3-3996152ec465' \ -object '{"id":"throttle-drive-efidisk0","limits":{},"qom-type":"throttle-group"}' \ - -blockdev '{"driver":"raw","file":{"driver":"file","filename":"/usr/share/pve-edk2-firmware//OVMF_CVM_CODE_4M.fd"},"node-name":"pflash0","read-only":true}' \ + -blockdev '{"driver":"raw","file":{"driver":"file","filename":"/usr/share/pve-edk2-firmware//OVMF_SEV_CODE_4M.fd"},"node-name":"pflash0","read-only":true}' \ -blockdev '{"detect-zeroes":"on","discard":"ignore","driver":"throttle","file":{"cache":{"direct":false,"no-flush":false},"detect-zeroes":"on","discard":"ignore","driver":"raw","file":{"aio":"io_uring","cache":{"direct":false,"no-flush":false},"detect-zeroes":"on","discard":"ignore","driver":"file","filename":"/var/lib/vz/images/100/vm-100-disk-0.raw","node-name":"e1175f2a490414e7c53337589fde17a","read-only":false},"node-name":"f1175f2a490414e7c53337589fde17a","read-only":false,"size":540672},"node-name":"drive-efidisk0","read-only":false,"throttle-group":"throttle-drive-efidisk0"}' \ -smp '1,sockets=1,cores=1,maxcpus=1' \ -nodefaults \ diff --git a/src/test/cfg2cmd/sev-snp.conf.cmd b/src/test/cfg2cmd/sev-snp.conf.cmd index 3308e86e..14b55d3e 100644 --- a/src/test/cfg2cmd/sev-snp.conf.cmd +++ b/src/test/cfg2cmd/sev-snp.conf.cmd @@ -9,7 +9,7 @@ -pidfile /var/run/qemu-server/8006.pid \ -daemonize \ -smbios 'type=1,uuid=7b10d7af-b932-4c66-b2c3-3996152ec465' \ - -bios /usr/share/pve-edk2-firmware//OVMF_CVM_4M.fd \ + -bios /usr/share/pve-edk2-firmware//OVMF_SEV_4M.fd \ -smp '1,sockets=1,cores=1,maxcpus=1' \ -nodefaults \ -boot 'menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg' \ diff --git a/src/test/cfg2cmd/sev-std.conf.cmd b/src/test/cfg2cmd/sev-std.conf.cmd index 6291a302..c23fe6d2 100644 --- a/src/test/cfg2cmd/sev-std.conf.cmd +++ b/src/test/cfg2cmd/sev-std.conf.cmd @@ -10,7 +10,7 @@ -daemonize \ -smbios 'type=1,uuid=7b10d7af-b932-4c66-b2c3-3996152ec465' \ -object '{"id":"throttle-drive-efidisk0","limits":{},"qom-type":"throttle-group"}' \ - -blockdev '{"driver":"raw","file":{"driver":"file","filename":"/usr/share/pve-edk2-firmware//OVMF_CVM_CODE_4M.fd"},"node-name":"pflash0","read-only":true}' \ + -blockdev '{"driver":"raw","file":{"driver":"file","filename":"/usr/share/pve-edk2-firmware//OVMF_SEV_CODE_4M.fd"},"node-name":"pflash0","read-only":true}' \ -blockdev '{"detect-zeroes":"on","discard":"ignore","driver":"throttle","file":{"cache":{"direct":false,"no-flush":false},"detect-zeroes":"on","discard":"ignore","driver":"raw","file":{"aio":"io_uring","cache":{"direct":false,"no-flush":false},"detect-zeroes":"on","discard":"ignore","driver":"file","filename":"/var/lib/vz/images/100/vm-100-disk-0.raw","node-name":"e1175f2a490414e7c53337589fde17a","read-only":false},"node-name":"f1175f2a490414e7c53337589fde17a","read-only":false,"size":540672},"node-name":"drive-efidisk0","read-only":false,"throttle-group":"throttle-drive-efidisk0"}' \ -smp '1,sockets=1,cores=1,maxcpus=1' \ -nodefaults \ -- 2.43.0 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [pve-devel] [PATCH qemu-server v2 1/3] Adapt AMD SEV code for compatibility with other platforms 2025-10-01 15:11 ` [pve-devel] [PATCH qemu-server v2 1/3] Adapt AMD SEV code for compatibility with other platforms Anton Iacobaeus @ 2025-10-07 15:24 ` Fiona Ebner 0 siblings, 0 replies; 20+ messages in thread From: Fiona Ebner @ 2025-10-07 15:24 UTC (permalink / raw) To: Proxmox VE development discussion, Anton Iacobaeus; +Cc: Philipp Giersfeld I plan to continue with the review tomorrow, looking good so far :)! Am 04.10.25 um 3:24 PM schrieb Anton Iacobaeus: > From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> > > Change variable and function names that are specific to AMD SEV to > reflect this. Also, change name of general CC functions and variable > names to be used in conjunction with other platforms. > > Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> > Signed-off-by: Anton Iacobaeus <anton.iacobaeus@canarybit.eu> Reviewed-by: Fiona Ebner <f.ebner@proxmox.com> > --- Note for applying: needs a depends and build-depends on new pve-edk2-firmware-ovmf > @@ -49,19 +49,19 @@ my $OVMF = { > }; > > my sub get_ovmf_files($$$$) { > - my ($arch, $efidisk, $smm, $amd_sev_type) = @_; > + my ($arch, $efidisk, $smm, $cvm_type) = @_; > > my $types = $OVMF->{$arch} > or die "no OVMF images known for architecture '$arch'\n"; > > my $type = 'default'; > if ($arch eq 'x86_64') { > - if ($amd_sev_type && $amd_sev_type eq 'snp') { > + if ($cvm_type && $cvm_type eq 'snp') { > $type = "4m-snp"; > my ($ovmf) = $types->{$type}->@*; > die "EFI base image '$ovmf' not found\n" if !-f $ovmf; > return ($ovmf); > - } elsif ($amd_sev_type) { > + } elsif ($cvm_type && ($cvm_type eq 'std' || $cvm_type eq 'es')) { > $type = "4m-sev"; Nit and this is pre-existing, but it would be nice to detect an unknown type here for future-proofing/robustness (Perl's lack of type system makes this hard to enforce up-front). Something like } elsif ($cmv_type) { die "unknown CMV type $cmv_type\n"; But this should be a separate patch and can also be done as a follow-up after adding the branch for the Intel one. > } elsif (defined($efidisk->{efitype}) && $efidisk->{efitype} eq '4m') { > $type = $smm ? "4m" : "4m-no-smm"; > @@ -203,16 +203,16 @@ my sub generate_ovmf_blockdev { > sub print_ovmf_commandline { > my ($conf, $storecfg, $vmid, $hw_info, $version_guard, $readonly) = @_; > > - my $amd_sev_type = $hw_info->{'amd-sev-type'}; > + my $cvm_type = $hw_info->{'cvm-type'}; > > my $cmd = []; > my $machine_flags = []; > > - if ($amd_sev_type && $amd_sev_type eq 'snp') { > + if ($cvm_type && $cvm_type eq 'snp') { > if (defined($conf->{efidisk0})) { > - log_warn("EFI disks are not supported with SEV-SNP and will be ignored"); > + log_warn("EFI disks are not supported with Confidential Virtual Machines and will be ignored"); Style nit: line longer than 100 characters > } > - push $cmd->@*, '-bios', get_ovmf_files($hw_info->{arch}, undef, undef, $amd_sev_type); > + push $cmd->@*, '-bios', get_ovmf_files($hw_info->{arch}, undef, undef, $cvm_type); > } else { > if ($version_guard->(10, 0, 0)) { # for the switch to -blockdev > my ($code_blockdev, $vars_blockdev, $throttle_group) = _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* [pve-devel] [PATCH qemu-server v2 2/3] Add check for TDX support 2025-10-01 15:11 [pve-devel] [PATCH edk2-firmware/manager/qemu-server v2 0/7] Add support for Intel TDX Anton Iacobaeus ` (4 preceding siblings ...) 2025-10-01 15:11 ` [pve-devel] [PATCH qemu-server v2 1/3] Adapt AMD SEV code for compatibility with other platforms Anton Iacobaeus @ 2025-10-01 15:11 ` Anton Iacobaeus 2025-10-08 10:06 ` Fiona Ebner 2025-10-01 15:11 ` [pve-devel] [PATCH qemu-server v2 3/3] Add support for Intel TDX Anton Iacobaeus 6 siblings, 1 reply; 20+ messages in thread From: Anton Iacobaeus @ 2025-10-01 15:11 UTC (permalink / raw) To: pve-devel; +Cc: Philipp Giersfeld From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> Check whether TDX is enabled on this machine. Instead of using CPUID like AMD SEV, Intel TDX enablement can be verified by reading an MSR (https://cc-enabling.trustedservices.intel.com/intel-tdx-enabling-guide/05/host_os_setup/). Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> Signed-off-by: Anton Iacobaeus <anton.iacobaeus@canarybit.eu> --- .../query-machine-capabilities.c | 97 ++++++++++++++++--- src/usr/modules-load.conf | 1 + 2 files changed, 85 insertions(+), 13 deletions(-) diff --git a/src/query-machine-capabilities/query-machine-capabilities.c b/src/query-machine-capabilities/query-machine-capabilities.c index 0c522afc..5bc39450 100644 --- a/src/query-machine-capabilities/query-machine-capabilities.c +++ b/src/query-machine-capabilities/query-machine-capabilities.c @@ -4,6 +4,8 @@ #include <sys/stat.h> #include <errno.h> #include <string.h> +#include <unistd.h> +#include <fcntl.h> #define eprintf(...) fprintf(stderr, __VA_ARGS__) @@ -18,17 +20,56 @@ typedef struct { uint8_t cbitpos; uint8_t reduced_phys_bits; -} cpu_caps_t; +} cpu_caps_amd_sev_t; -void query_cpu_capabilities(cpu_caps_t *res) { +typedef struct { + bool tdx_support; +} cpu_caps_intel_tdx_t; + +int read_msr(uint32_t msr_index, unsigned int *value) { + int64_t data; + char* msr_file_name = "/dev/cpu/0/msr"; + int fd; + + fd = open(msr_file_name, O_RDONLY); + if (fd < 0) { + if (errno == ENXIO) { + eprintf("rdmsr: No CPU 0\n"); + return -1; + } else if (errno == EIO) { + eprintf("rdmsr: CPU doesn't support MSRs\n"); + return -1; + } else { + perror("rdmsr: failed to open MSR"); + return -1; + } + } + + if (pread(fd, &data, sizeof data, msr_index) != sizeof data) { + if (errno == EIO) { + eprintf("rdmsr: CPU cannot read MSR 0x%08x\n", msr_index); + return -1; + } else { + perror("rdmsr: pread"); + return -1; + } + } + + *value = data; + + close(fd); + return 0; +} + +void query_cpu_capabilities_sev(cpu_caps_amd_sev_t *res) { uint32_t eax, ebx, ecx, edx; // query Encrypted Memory Capabilities, see: // https://en.wikipedia.org/wiki/CPUID#EAX=8000001Fh:_Encrypted_Memory_Capabilities uint32_t query_function = 0x8000001F; asm volatile("cpuid" - : "=a"(eax), "=b"(ebx), "=c"(ecx), "=d"(edx) - : "0"(query_function) + : "=a"(eax), "=b"(ebx), "=c"(ecx), "=d"(edx) + : "0"(query_function) ); res->sev_support = (eax & (1<<1)) != 0; @@ -39,6 +80,18 @@ void query_cpu_capabilities(cpu_caps_t *res) { res->reduced_phys_bits = (ebx >> 6) & 0x3f; } +int query_cpu_capabilities_tdx(cpu_caps_intel_tdx_t *res) { + unsigned int value; + + if (read_msr(0x1401, &value) == 0) { + res->tdx_support = (value & (1<<11)); + } else { + eprintf("Error reading MSR, Intel TDX support undetermined\n"); + return -1; + } + return 0; +} + int prepare_output_directory() { // Check that the directory exists and create it if it does not. struct stat statbuf; @@ -65,8 +118,8 @@ int main() { return 1; } - cpu_caps_t caps; - query_cpu_capabilities(&caps); + cpu_caps_amd_sev_t caps_sev; + query_cpu_capabilities_sev(&caps_sev); FILE *file = fopen(OUTPUT_PATH, "w"); if (file == NULL) { @@ -82,18 +135,36 @@ int main() { " \"sev-support\": %s," " \"sev-support-es\": %s," " \"sev-support-snp\": %s" - " }" - " }\n", - caps.cbitpos, - caps.reduced_phys_bits, - caps.sev_support ? "true" : "false", - caps.sev_es_support ? "true" : "false", - caps.sev_snp_support ? "true" : "false" + " }", + caps_sev.cbitpos, + caps_sev.reduced_phys_bits, + caps_sev.sev_support ? "true" : "false", + caps_sev.sev_es_support ? "true" : "false", + caps_sev.sev_snp_support ? "true" : "false" ); if (ret < 0) { eprintf("Error writing to file '" OUTPUT_PATH "': %s\n", strerror(errno)); } + cpu_caps_intel_tdx_t caps_tdx; + if (query_cpu_capabilities_tdx(&caps_tdx) == 0) { + ret = fprintf(file, + "," + " \"intel-tdx\": {" + " \"tdx-support\": %s" + " }", + caps_tdx.tdx_support ? "true" : "false" + ); + if (ret < 0) { + eprintf("Error writing to file '" OUTPUT_PATH "': %s\n", strerror(errno)); + } + } + + ret = fprintf(file, " }\n"); + if (ret < 0) { + eprintf("Error writing to file '" OUTPUT_PATH "': %s\n", strerror(errno)); + } + ret = fclose(file); if (ret != 0) { eprintf("Error closing file '" OUTPUT_PATH "': %s\n", strerror(errno)); diff --git a/src/usr/modules-load.conf b/src/usr/modules-load.conf index aee7d42a..f45d256b 100644 --- a/src/usr/modules-load.conf +++ b/src/usr/modules-load.conf @@ -1 +1,2 @@ vhost_net +msr -- 2.43.0 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [pve-devel] [PATCH qemu-server v2 2/3] Add check for TDX support 2025-10-01 15:11 ` [pve-devel] [PATCH qemu-server v2 2/3] Add check for TDX support Anton Iacobaeus @ 2025-10-08 10:06 ` Fiona Ebner 0 siblings, 0 replies; 20+ messages in thread From: Fiona Ebner @ 2025-10-08 10:06 UTC (permalink / raw) To: Proxmox VE development discussion, Anton Iacobaeus Am 04.10.25 um 3:23 PM schrieb Anton Iacobaeus: > From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> > > Check whether TDX is enabled on this machine. Instead of using CPUID > like AMD SEV, Intel TDX enablement can be verified by reading an MSR > (https://cc-enabling.trustedservices.intel.com/intel-tdx-enabling-guide/05/host_os_setup/). > > Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> > Signed-off-by: Anton Iacobaeus <anton.iacobaeus@canarybit.eu> > --- > .../query-machine-capabilities.c | 97 ++++++++++++++++--- > src/usr/modules-load.conf | 1 + > 2 files changed, 85 insertions(+), 13 deletions(-) > > diff --git a/src/query-machine-capabilities/query-machine-capabilities.c b/src/query-machine-capabilities/query-machine-capabilities.c > index 0c522afc..5bc39450 100644 > --- a/src/query-machine-capabilities/query-machine-capabilities.c > +++ b/src/query-machine-capabilities/query-machine-capabilities.c > @@ -4,6 +4,8 @@ > #include <sys/stat.h> > #include <errno.h> > #include <string.h> > +#include <unistd.h> > +#include <fcntl.h> > > #define eprintf(...) fprintf(stderr, __VA_ARGS__) > > @@ -18,17 +20,56 @@ typedef struct { > > uint8_t cbitpos; > uint8_t reduced_phys_bits; > -} cpu_caps_t; > +} cpu_caps_amd_sev_t; > > -void query_cpu_capabilities(cpu_caps_t *res) { > +typedef struct { > + bool tdx_support; Should we also check for Intel TME and SGX as described in the guide you referenced? > +} cpu_caps_intel_tdx_t; > + > +int read_msr(uint32_t msr_index, unsigned int *value) { > + int64_t data; It would be nicer if 'data' and 'value' are the same type (apart from the pointer). Both could be uint64_t, or? For value, it should also be adapted on the call site if going for this. > + char* msr_file_name = "/dev/cpu/0/msr"; > + int fd; > + > + fd = open(msr_file_name, O_RDONLY); > + if (fd < 0) { > + if (errno == ENXIO) { > + eprintf("rdmsr: No CPU 0\n"); > + return -1; > + } else if (errno == EIO) { > + eprintf("rdmsr: CPU doesn't support MSRs\n"); > + return -1; > + } else { > + perror("rdmsr: failed to open MSR"); > + return -1; > + } > + } > + > + if (pread(fd, &data, sizeof data, msr_index) != sizeof data) { Style nit: I'd prefer sizeof() with parentheses, because it eases reading a bit and is more common in my experience > + if (errno == EIO) { > + eprintf("rdmsr: CPU cannot read MSR 0x%08x\n", msr_index); > + return -1; > + } else { > + perror("rdmsr: pread"); > + return -1; > + } > + } > + > + *value = data; > + > + close(fd); > + return 0; > +} > + > +void query_cpu_capabilities_sev(cpu_caps_amd_sev_t *res) { > uint32_t eax, ebx, ecx, edx; > > // query Encrypted Memory Capabilities, see: > // https://en.wikipedia.org/wiki/CPUID#EAX=8000001Fh:_Encrypted_Memory_Capabilities > uint32_t query_function = 0x8000001F; > asm volatile("cpuid" > - : "=a"(eax), "=b"(ebx), "=c"(ecx), "=d"(edx) > - : "0"(query_function) > + : "=a"(eax), "=b"(ebx), "=c"(ecx), "=d"(edx) > + : "0"(query_function) > ); > > res->sev_support = (eax & (1<<1)) != 0; > @@ -39,6 +80,18 @@ void query_cpu_capabilities(cpu_caps_t *res) { > res->reduced_phys_bits = (ebx >> 6) & 0x3f; > } > > +int query_cpu_capabilities_tdx(cpu_caps_intel_tdx_t *res) { > + unsigned int value; > + > + if (read_msr(0x1401, &value) == 0) { > + res->tdx_support = (value & (1<<11)); > + } else { > + eprintf("Error reading MSR, Intel TDX support undetermined\n"); Nit: Since the register is expected to not be there for many CPUs, should we rather say "Cannot read" instead of "Error reading"? Error makes it sound like something is wrong which is not necessarily the case. Just to avoid admins getting nervous ;) Or maybe even just reduce the message to "Intel TDX support undetermined", the actual info what happened is already printed inside read_msr(). > + return -1; > + } > + return 0; > +} > + > int prepare_output_directory() { > // Check that the directory exists and create it if it does not. > struct stat statbuf; > @@ -65,8 +118,8 @@ int main() { > return 1; > } > > - cpu_caps_t caps; > - query_cpu_capabilities(&caps); > + cpu_caps_amd_sev_t caps_sev; > + query_cpu_capabilities_sev(&caps_sev); Pre-existing, but should we try to detect whether the CPU is AMD or Intel right away and then only do the relevant call? Otherwise, we risk the JSON claiming support for the other vendor's feature, because we query data in a way that doesn't make sense for the current vendor. Also to not show the error messages for AMD CPUs on every boot: Oct 08 11:50:21 pve9a1 query-machine-capabilities[1139]: rdmsr: CPU cannot read MSR 0x00001401 Oct 08 11:50:21 pve9a1 query-machine-capabilities[1139]: Error reading MSR, Intel TDX support undetermined > > FILE *file = fopen(OUTPUT_PATH, "w"); > if (file == NULL) { > @@ -82,18 +135,36 @@ int main() { > " \"sev-support\": %s," > " \"sev-support-es\": %s," > " \"sev-support-snp\": %s" > - " }" > - " }\n", > - caps.cbitpos, > - caps.reduced_phys_bits, > - caps.sev_support ? "true" : "false", > - caps.sev_es_support ? "true" : "false", > - caps.sev_snp_support ? "true" : "false" > + " }", > + caps_sev.cbitpos, > + caps_sev.reduced_phys_bits, > + caps_sev.sev_support ? "true" : "false", > + caps_sev.sev_es_support ? "true" : "false", > + caps_sev.sev_snp_support ? "true" : "false" > ); > if (ret < 0) { > eprintf("Error writing to file '" OUTPUT_PATH "': %s\n", strerror(errno)); > } > > + cpu_caps_intel_tdx_t caps_tdx; > + if (query_cpu_capabilities_tdx(&caps_tdx) == 0) { > + ret = fprintf(file, > + "," > + " \"intel-tdx\": {" > + " \"tdx-support\": %s" > + " }", > + caps_tdx.tdx_support ? "true" : "false" > + ); > + if (ret < 0) { > + eprintf("Error writing to file '" OUTPUT_PATH "': %s\n", strerror(errno)); > + } > + } > + > + ret = fprintf(file, " }\n"); > + if (ret < 0) { > + eprintf("Error writing to file '" OUTPUT_PATH "': %s\n", strerror(errno)); > + } > + > ret = fclose(file); > if (ret != 0) { > eprintf("Error closing file '" OUTPUT_PATH "': %s\n", strerror(errno)); > diff --git a/src/usr/modules-load.conf b/src/usr/modules-load.conf > index aee7d42a..f45d256b 100644 > --- a/src/usr/modules-load.conf > +++ b/src/usr/modules-load.conf > @@ -1 +1,2 @@ > vhost_net > +msr _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* [pve-devel] [PATCH qemu-server v2 3/3] Add support for Intel TDX 2025-10-01 15:11 [pve-devel] [PATCH edk2-firmware/manager/qemu-server v2 0/7] Add support for Intel TDX Anton Iacobaeus ` (5 preceding siblings ...) 2025-10-01 15:11 ` [pve-devel] [PATCH qemu-server v2 2/3] Add check for TDX support Anton Iacobaeus @ 2025-10-01 15:11 ` Anton Iacobaeus 2025-10-08 10:21 ` Fiona Ebner 6 siblings, 1 reply; 20+ messages in thread From: Anton Iacobaeus @ 2025-10-01 15:11 UTC (permalink / raw) To: pve-devel; +Cc: Philipp Giersfeld From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> This commit adds support for setting up an Intel TDX VM. A Intel TDX VM can be setup similar to AMD SEV but uses a different firmware image. Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> Signed-off-by: Anton Iacobaeus <anton.iacobaeus@canarybit.eu> --- src/PVE/QemuMigrate/Helpers.pm | 1 + src/PVE/QemuServer.pm | 21 +++++++++++++++++++-- src/PVE/QemuServer/CPUConfig.pm | 31 +++++++++++++++++++++++++++++++ src/PVE/QemuServer/OVMF.pm | 13 ++++++++++++- 4 files changed, 63 insertions(+), 3 deletions(-) diff --git a/src/PVE/QemuMigrate/Helpers.pm b/src/PVE/QemuMigrate/Helpers.pm index f191565a..466517da 100644 --- a/src/PVE/QemuMigrate/Helpers.pm +++ b/src/PVE/QemuMigrate/Helpers.pm @@ -20,6 +20,7 @@ sub check_non_migratable_resources { my @blockers = (); if ($state) { push @blockers, "amd-sev" if $conf->{"amd-sev"}; + push @blockers, "intel-tdx" if $conf->{"intel-tdx"}; push @blockers, "virtiofs" if PVE::QemuServer::Virtiofs::virtiofs_enabled($conf); } diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm index eb2a8c7e..bb5a0a8e 100644 --- a/src/PVE/QemuServer.pm +++ b/src/PVE/QemuServer.pm @@ -60,8 +60,15 @@ use PVE::QemuServer::Helpers qw(config_aware_timeout get_iscsi_initiator_name min_version kvm_user_version windows_version); use PVE::QemuServer::Cloudinit; use PVE::QemuServer::CGroup; -use PVE::QemuServer::CPUConfig - qw(print_cpu_device get_cpu_options get_cpu_bitness is_native_arch get_amd_sev_object get_cvm_type); +use PVE::QemuServer::CPUConfig qw( + print_cpu_device + get_cpu_options + get_cpu_bitness + is_native_arch + get_amd_sev_object + get_intel_tdx_object + get_cvm_type + ); use PVE::QemuServer::Drive qw( is_valid_drivename checked_volume_format @@ -323,6 +330,12 @@ my $confdesc = { format => 'pve-qemu-sev-fmt', type => 'string', }, + 'intel-tdx' => { + description => "Trusted Domain Extension (TDX) features by Intel CPUs", + optional => 1, + format => 'pve-qemu-tdx-fmt', + type => 'string', + }, balloon => { optional => 1, type => 'integer', @@ -3965,6 +3978,10 @@ sub config_to_command { if ($conf->{'amd-sev'}) { push @$devices, '-object', get_amd_sev_object($conf->{'amd-sev'}, $conf->{bios}); push @$machineFlags, 'confidential-guest-support=sev0'; + } elsif ($conf->{'intel-tdx'}) { + push @$devices, '-object', get_intel_tdx_object($conf->{'intel-tdx'}, $conf->{bios}); + push @$machineFlags, 'confidential-guest-support=tdx0'; + push @$machineFlags, 'kernel_irqchip=split'; } PVE::QemuServer::Virtiofs::config($conf, $vmid, $devices); diff --git a/src/PVE/QemuServer/CPUConfig.pm b/src/PVE/QemuServer/CPUConfig.pm index 65a7b565..bd5540e6 100644 --- a/src/PVE/QemuServer/CPUConfig.pm +++ b/src/PVE/QemuServer/CPUConfig.pm @@ -18,6 +18,7 @@ our @EXPORT_OK = qw( get_cpu_bitness is_native_arch get_amd_sev_object + get_intel_tdx_object get_cvm_type ); @@ -282,6 +283,18 @@ my $sev_fmt = { }; PVE::JSONSchema::register_format('pve-qemu-sev-fmt', $sev_fmt); +my $tdx_fmt = { + type => { + description => "Enable TDX", + type => 'string', + default_key => 1, + format_description => "tdx-type", + enum => ['tdx'], + maxLength => 3, + }, +}; +PVE::JSONSchema::register_format('pve-qemu-tdx-fmt', $tdx_fmt); + PVE::JSONSchema::register_format('pve-phys-bits', \&parse_phys_bits); sub parse_phys_bits { @@ -887,6 +900,9 @@ sub get_cvm_type { if ($conf->{'amd-sev'}) { my $sev = PVE::JSONSchema::parse_property_string($sev_fmt, $conf->{'amd-sev'}); return $sev->{type}; + } elsif ($conf->{'intel-tdx'}) { + my $tdx = PVE::JSONSchema::parse_property_string($tdx_fmt, $conf->{'intel-tdx'}); + return $tdx->{type}; } else { return undef; } @@ -945,6 +961,21 @@ sub get_amd_sev_object { return $sev_mem_object; } +sub get_intel_tdx_object { + my ($intel_tdx, $bios) = @_; + my $intel_tdx_conf = PVE::JSONSchema::parse_property_string($tdx_fmt, $intel_tdx); + my $tdx_hw_caps = get_hw_capabilities()->{'intel-tdx'}; + + if (!$tdx_hw_caps->{'tdx-support'}) { + die "Your CPU does not support Intel TDX.\n"; + } + if (!$bios || $bios ne 'ovmf') { + die "To use Intel TDX, you need to change the BIOS to OVMF.\n"; + } + my $tdx_mem_object = 'tdx-guest,id=tdx0'; + return $tdx_mem_object; +} + __PACKAGE__->register(); __PACKAGE__->init(); diff --git a/src/PVE/QemuServer/OVMF.pm b/src/PVE/QemuServer/OVMF.pm index df44d3f1..4253914c 100644 --- a/src/PVE/QemuServer/OVMF.pm +++ b/src/PVE/QemuServer/OVMF.pm @@ -34,6 +34,9 @@ my $OVMF = { '4m-snp' => [ "$EDK2_FW_BASE/OVMF_SEV_4M.fd", ], + '4m-tdx' => [ + "$EDK2_FW_BASE/OVMF_TDX_4M.fd", + ], # FIXME: These are legacy 2MB-sized images that modern OVMF doesn't supports to build # anymore. how can we deperacate this sanely without breaking existing instances, or using # older backups and snapshot? @@ -63,6 +66,11 @@ my sub get_ovmf_files($$$$) { return ($ovmf); } elsif ($cvm_type && ($cvm_type eq 'std' || $cvm_type eq 'es')) { $type = "4m-sev"; + } elsif ($cvm_type && $cvm_type eq 'tdx') { + $type = "4m-tdx"; + my ($ovmf) = $types->{$type}->@*; + die "EFI base image '$ovmf' not found\n" if ! -f $ovmf; + return ($ovmf); } elsif (defined($efidisk->{efitype}) && $efidisk->{efitype} eq '4m') { $type = $smm ? "4m" : "4m-no-smm"; $type .= '-ms' if $efidisk->{'pre-enrolled-keys'}; @@ -88,6 +96,9 @@ my sub print_ovmf_drive_commandlines { die "Attempting to configure SEV-SNP with pflash devices instead of using `-bios`\n" if $cvm_type && $cvm_type eq 'snp'; + die "Attempting to configure TDX with pflash devices instead of using `-bios`\n" + if $cvm_type && $cvm_type eq 'tdx'; + my ($ovmf_code, $ovmf_vars) = get_ovmf_files($arch, $d, $q35, $cvm_type); my $var_drive_str = "if=pflash,unit=1,id=drive-efidisk0"; @@ -208,7 +219,7 @@ sub print_ovmf_commandline { my $cmd = []; my $machine_flags = []; - if ($cvm_type && $cvm_type eq 'snp') { + if ($cvm_type && ($cvm_type eq 'snp' || $cvm_type eq 'tdx')) { if (defined($conf->{efidisk0})) { log_warn("EFI disks are not supported with Confidential Virtual Machines and will be ignored"); } -- 2.43.0 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [pve-devel] [PATCH qemu-server v2 3/3] Add support for Intel TDX 2025-10-01 15:11 ` [pve-devel] [PATCH qemu-server v2 3/3] Add support for Intel TDX Anton Iacobaeus @ 2025-10-08 10:21 ` Fiona Ebner 2025-10-13 9:30 ` Fiona Ebner 0 siblings, 1 reply; 20+ messages in thread From: Fiona Ebner @ 2025-10-08 10:21 UTC (permalink / raw) To: Proxmox VE development discussion, Anton Iacobaeus Am 04.10.25 um 3:23 PM schrieb Anton Iacobaeus: > From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> > > This commit adds support for setting up an Intel TDX VM. A Intel TDX VM > can be setup similar to AMD SEV but uses a different firmware image. > > Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> > Signed-off-by: Anton Iacobaeus <anton.iacobaeus@canarybit.eu> Apart from a few nits, see below: Reviewed-by: Fiona Ebner <f.ebner@proxmox.com> > @@ -3965,6 +3978,10 @@ sub config_to_command { > if ($conf->{'amd-sev'}) { > push @$devices, '-object', get_amd_sev_object($conf->{'amd-sev'}, $conf->{bios}); > push @$machineFlags, 'confidential-guest-support=sev0'; > + } elsif ($conf->{'intel-tdx'}) { > + push @$devices, '-object', get_intel_tdx_object($conf->{'intel-tdx'}, $conf->{bios}); > + push @$machineFlags, 'confidential-guest-support=tdx0'; > + push @$machineFlags, 'kernel_irqchip=split'; Nit: would be nice to have a comment describing the rationale behind the kernel_irqchip option and/or a sentence in the commit message. > } > > PVE::QemuServer::Virtiofs::config($conf, $vmid, $devices); > diff --git a/src/PVE/QemuServer/CPUConfig.pm b/src/PVE/QemuServer/CPUConfig.pm > index 65a7b565..bd5540e6 100644 > --- a/src/PVE/QemuServer/CPUConfig.pm > +++ b/src/PVE/QemuServer/CPUConfig.pm > @@ -18,6 +18,7 @@ our @EXPORT_OK = qw( > get_cpu_bitness > is_native_arch > get_amd_sev_object > + get_intel_tdx_object > get_cvm_type > ); > > @@ -282,6 +283,18 @@ my $sev_fmt = { > }; > PVE::JSONSchema::register_format('pve-qemu-sev-fmt', $sev_fmt); > > +my $tdx_fmt = { > + type => { > + description => "Enable TDX", > + type => 'string', > + default_key => 1, > + format_description => "tdx-type", > + enum => ['tdx'], > + maxLength => 3, Nit: There is an explicit enum already, so this is superfluous and needs to be dropped/updated as soon as a variant with a longer name appears > + }, > +}; > +PVE::JSONSchema::register_format('pve-qemu-tdx-fmt', $tdx_fmt); > + > PVE::JSONSchema::register_format('pve-phys-bits', \&parse_phys_bits); > > sub parse_phys_bits { > @@ -887,6 +900,9 @@ sub get_cvm_type { > if ($conf->{'amd-sev'}) { > my $sev = PVE::JSONSchema::parse_property_string($sev_fmt, $conf->{'amd-sev'}); > return $sev->{type}; > + } elsif ($conf->{'intel-tdx'}) { > + my $tdx = PVE::JSONSchema::parse_property_string($tdx_fmt, $conf->{'intel-tdx'}); > + return $tdx->{type}; > } else { > return undef; > } > @@ -945,6 +961,21 @@ sub get_amd_sev_object { > return $sev_mem_object; > } > > +sub get_intel_tdx_object { > + my ($intel_tdx, $bios) = @_; > + my $intel_tdx_conf = PVE::JSONSchema::parse_property_string($tdx_fmt, $intel_tdx); > + my $tdx_hw_caps = get_hw_capabilities()->{'intel-tdx'}; > + Style nit: additional whitespace above here > + if (!$tdx_hw_caps->{'tdx-support'}) { > + die "Your CPU does not support Intel TDX.\n"; Style nit: a tab snuck in here, you can use 'make tidy' to have the code formatted nowadays > + } > + if (!$bios || $bios ne 'ovmf') { > + die "To use Intel TDX, you need to change the BIOS to OVMF.\n"; Style nit: same here > + } > + my $tdx_mem_object = 'tdx-guest,id=tdx0'; Style nit: pre-existing with AMD SEV, but I'd not use _mem_ in the varialbe name here. It could also just be a direct return of the string. > + return $tdx_mem_object; > +} > + > __PACKAGE__->register(); > __PACKAGE__->init(); > _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [pve-devel] [PATCH qemu-server v2 3/3] Add support for Intel TDX 2025-10-08 10:21 ` Fiona Ebner @ 2025-10-13 9:30 ` Fiona Ebner 2025-10-13 14:25 ` Anton Iacobaeus 0 siblings, 1 reply; 20+ messages in thread From: Fiona Ebner @ 2025-10-13 9:30 UTC (permalink / raw) To: Proxmox VE development discussion, Anton Iacobaeus Am 08.10.25 um 12:21 PM schrieb Fiona Ebner: > Am 04.10.25 um 3:23 PM schrieb Anton Iacobaeus: >> From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> >> >> This commit adds support for setting up an Intel TDX VM. A Intel TDX VM >> can be setup similar to AMD SEV but uses a different firmware image. >> >> Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> >> Signed-off-by: Anton Iacobaeus <anton.iacobaeus@canarybit.eu> > > Apart from a few nits, see below: > Reviewed-by: Fiona Ebner <f.ebner@proxmox.com> >> @@ -3965,6 +3978,10 @@ sub config_to_command { >> if ($conf->{'amd-sev'}) { >> push @$devices, '-object', get_amd_sev_object($conf->{'amd-sev'}, $conf->{bios}); >> push @$machineFlags, 'confidential-guest-support=sev0'; >> + } elsif ($conf->{'intel-tdx'}) { >> + push @$devices, '-object', get_intel_tdx_object($conf->{'intel-tdx'}, $conf->{bios}); >> + push @$machineFlags, 'confidential-guest-support=tdx0'; >> + push @$machineFlags, 'kernel_irqchip=split'; One more thing I noticed/remembered: Don't we also need something like -device vhost-vsock-pci,guest-cid=3 for communication between QGS and TD VM like described in the docs: https://cc-enabling.trustedservices.intel.com/intel-tdx-enabling-guide/05/host_os_setup/#setup-communication-path-between-qgs-and-td ? > > Nit: would be nice to have a comment describing the rationale behind the > kernel_irqchip option and/or a sentence in the commit message. > >> } >> >> PVE::QemuServer::Virtiofs::config($conf, $vmid, $devices); _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [pve-devel] [PATCH qemu-server v2 3/3] Add support for Intel TDX 2025-10-13 9:30 ` Fiona Ebner @ 2025-10-13 14:25 ` Anton Iacobaeus 2025-10-14 7:50 ` Fiona Ebner 0 siblings, 1 reply; 20+ messages in thread From: Anton Iacobaeus @ 2025-10-13 14:25 UTC (permalink / raw) To: Proxmox VE development discussion On 10/13/25 11:30, Fiona Ebner wrote: > Am 08.10.25 um 12:21 PM schrieb Fiona Ebner: >> Am 04.10.25 um 3:23 PM schrieb Anton Iacobaeus: >>> From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> >>> >>> This commit adds support for setting up an Intel TDX VM. A Intel TDX VM >>> can be setup similar to AMD SEV but uses a different firmware image. >>> >>> Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> >>> Signed-off-by: Anton Iacobaeus <anton.iacobaeus@canarybit.eu> >> >> Apart from a few nits, see below: >> Reviewed-by: Fiona Ebner <f.ebner@proxmox.com> >>> @@ -3965,6 +3978,10 @@ sub config_to_command { >>> if ($conf->{'amd-sev'}) { >>> push @$devices, '-object', get_amd_sev_object($conf->{'amd-sev'}, $conf->{bios}); >>> push @$machineFlags, 'confidential-guest-support=sev0'; >>> + } elsif ($conf->{'intel-tdx'}) { >>> + push @$devices, '-object', get_intel_tdx_object($conf->{'intel-tdx'}, $conf->{bios}); >>> + push @$machineFlags, 'confidential-guest-support=tdx0'; >>> + push @$machineFlags, 'kernel_irqchip=split'; > > One more thing I noticed/remembered: > > Don't we also need something like > -device vhost-vsock-pci,guest-cid=3 > > for communication between QGS and TD VM like described in the docs: > https://cc-enabling.trustedservices.intel.com/intel-tdx-enabling-guide/05/host_os_setup/#setup-communication-path-between-qgs-and-td > > ? Yes you are correct, but it is only required for attestation support, which was initially out of scope for this series. The changes are however quite small and they could fit in this series. Note that TDX memory encryption works without any communication between the QGS and TD VM. The QGS is only contacted for quote generation. In terms of this particular device, it was only used in TDX Early Preview. Today a quote-generation-socket should instead be included directly in the TDX object, like this: -object '{"qom-type":"tdx-guest","id":"tdx","quote-generation-socket":{"type": "vsock", "cid":"2","port":"4050"}}' I think this change can be included in this series, but it adds some additional scope since the type, cid and port can be configured differently from these defaults. > >> >> Nit: would be nice to have a comment describing the rationale behind the >> kernel_irqchip option and/or a sentence in the commit message. >> >>> } >>> >>> PVE::QemuServer::Virtiofs::config($conf, $vmid, $devices); > Yes indeed, I will add that. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [pve-devel] [PATCH qemu-server v2 3/3] Add support for Intel TDX 2025-10-13 14:25 ` Anton Iacobaeus @ 2025-10-14 7:50 ` Fiona Ebner 0 siblings, 0 replies; 20+ messages in thread From: Fiona Ebner @ 2025-10-14 7:50 UTC (permalink / raw) To: Proxmox VE development discussion, Anton Iacobaeus Am 13.10.25 um 4:25 PM schrieb Anton Iacobaeus: > On 10/13/25 11:30, Fiona Ebner wrote: >> Am 08.10.25 um 12:21 PM schrieb Fiona Ebner: >>> Am 04.10.25 um 3:23 PM schrieb Anton Iacobaeus: >>>> From: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> >>>> >>>> This commit adds support for setting up an Intel TDX VM. A Intel TDX VM >>>> can be setup similar to AMD SEV but uses a different firmware image. >>>> >>>> Signed-off-by: Philipp Giersfeld <philipp.giersfeld@canarybit.eu> >>>> Signed-off-by: Anton Iacobaeus <anton.iacobaeus@canarybit.eu> >>> >>> Apart from a few nits, see below: >>> Reviewed-by: Fiona Ebner <f.ebner@proxmox.com> >>>> @@ -3965,6 +3978,10 @@ sub config_to_command { >>>> if ($conf->{'amd-sev'}) { >>>> push @$devices, '-object', get_amd_sev_object($conf- >>>> >{'amd-sev'}, $conf->{bios}); >>>> push @$machineFlags, 'confidential-guest-support=sev0'; >>>> + } elsif ($conf->{'intel-tdx'}) { >>>> + push @$devices, '-object', get_intel_tdx_object($conf- >>>> >{'intel-tdx'}, $conf->{bios}); >>>> + push @$machineFlags, 'confidential-guest-support=tdx0'; >>>> + push @$machineFlags, 'kernel_irqchip=split'; >> >> One more thing I noticed/remembered: >> >> Don't we also need something like >> -device vhost-vsock-pci,guest-cid=3 >> >> for communication between QGS and TD VM like described in the docs: >> https://cc-enabling.trustedservices.intel.com/intel-tdx-enabling- >> guide/05/host_os_setup/#setup-communication-path-between-qgs-and-td >> >> ? > Yes you are correct, but it is only required for attestation support, > which was initially out of scope for this series. The changes are > however quite small and they could fit in this series. > > Note that TDX memory encryption works without any communication between > the QGS and TD VM. The QGS is only contacted for quote generation. > > In terms of this particular device, it was only used in TDX Early > Preview. Today a quote-generation-socket should instead be included > directly in the TDX object, like this: > -object '{"qom-type":"tdx-guest","id":"tdx","quote-generation-socket": > {"type": "vsock", "cid":"2","port":"4050"}}' > > I think this change can be included in this series, but it adds some > additional scope since the type, cid and port can be configured > differently from these defaults. Thanks for the explanation! I'm fine with either way, but yes, if we do include it, it should be made configurable via the intel-tdx property string/$tdx_fmt. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2025-10-14 7:51 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2025-10-01 15:11 [pve-devel] [PATCH edk2-firmware/manager/qemu-server v2 0/7] Add support for Intel TDX Anton Iacobaeus 2025-10-01 15:11 ` [pve-devel] [PATCH edk2-firmware v2 1/3] Change name of SEV-related OVMF files Anton Iacobaeus 2025-10-07 15:24 ` Fiona Ebner 2025-10-01 15:11 ` [pve-devel] [PATCH edk2-firmware v2 2/3] Add firmware target for TDFV Anton Iacobaeus 2025-10-07 15:24 ` Fiona Ebner 2025-10-13 14:02 ` Anton Iacobaeus 2025-10-01 15:11 ` [pve-devel] [PATCH edk2-firmware v2 3/3] Add SCSI in NCCFV for TD guest Anton Iacobaeus 2025-10-07 15:24 ` Fiona Ebner 2025-10-13 14:02 ` Anton Iacobaeus 2025-10-14 7:50 ` Fiona Ebner 2025-10-01 15:11 ` [pve-devel] [PATCH manager v2 1/1] Add support for Intel TDX Anton Iacobaeus 2025-10-01 15:11 ` [pve-devel] [PATCH qemu-server v2 1/3] Adapt AMD SEV code for compatibility with other platforms Anton Iacobaeus 2025-10-07 15:24 ` Fiona Ebner 2025-10-01 15:11 ` [pve-devel] [PATCH qemu-server v2 2/3] Add check for TDX support Anton Iacobaeus 2025-10-08 10:06 ` Fiona Ebner 2025-10-01 15:11 ` [pve-devel] [PATCH qemu-server v2 3/3] Add support for Intel TDX Anton Iacobaeus 2025-10-08 10:21 ` Fiona Ebner 2025-10-13 9:30 ` Fiona Ebner 2025-10-13 14:25 ` Anton Iacobaeus 2025-10-14 7:50 ` Fiona Ebner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox