QEMU_CAPS_TDX_GUEST set means TDX supported with this QEMU.
Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com>
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
---
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 732c89fe29..3def894a22 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -741,6 +741,7 @@ VIR_ENUM_IMPL(virQEMUCaps,
"amd-iommu", /* QEMU_CAPS_AMD_IOMMU */
"amd-iommu.pci-id", /* QEMU_CAPS_AMD_IOMMU_PCI_ID */
"usb-bot", /* QEMU_CAPS_DEVICE_USB_BOT */
+ "tdx-guest", /* QEMU_CAPS_TDX_GUEST */
);
@@ -1429,6 +1430,7 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = {
{ "nvme-ns", QEMU_CAPS_DEVICE_NVME_NS },
{ "amd-iommu", QEMU_CAPS_AMD_IOMMU },
{ "usb-bot", QEMU_CAPS_DEVICE_USB_BOT },
+ { "tdx-guest", QEMU_CAPS_TDX_GUEST},
};
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index 966e30fa11..2c78ea14f3 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -722,6 +722,7 @@ typedef enum { /* virQEMUCapsFlags grouping marker for syntax-check */
QEMU_CAPS_AMD_IOMMU, /* -device amd-iommu */
QEMU_CAPS_AMD_IOMMU_PCI_ID, /* amd-iommu.pci-id */
QEMU_CAPS_DEVICE_USB_BOT, /* -device usb-bot */
+ QEMU_CAPS_TDX_GUEST, /* -object tdx-guest,... */
QEMU_CAPS_LAST /* this must always be the last item */
} virQEMUCapsFlags;
--
2.34.1On Wed, Jun 25, 2025 at 17:45:15 +0800, Zhenzhong Duan wrote: > QEMU_CAPS_TDX_GUEST set means TDX supported with this QEMU. > > Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> > Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> > --- > src/qemu/qemu_capabilities.c | 2 ++ > src/qemu/qemu_capabilities.h | 1 + > 2 files changed, 3 insertions(+) I presume that this is not yet supported by qemu since a qemu dump showing this capability is missing. Once there will be a released or in development qemu version that supports this please add a capability dump ( see tests/qemucapabilitiesdata/README.rst ) with the 'tdx' variant. A variant is needed because I don't have hardware supporting tdx so I can't be updating those on the main variant.
On Wed, Jun 25, 2025 at 01:19:34PM +0200, Peter Krempa wrote: > On Wed, Jun 25, 2025 at 17:45:15 +0800, Zhenzhong Duan wrote: > > QEMU_CAPS_TDX_GUEST set means TDX supported with this QEMU. > > > > Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> > > Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> > > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> > > --- > > src/qemu/qemu_capabilities.c | 2 ++ > > src/qemu/qemu_capabilities.h | 1 + > > 2 files changed, 3 insertions(+) > > I presume that this is not yet supported by qemu since a qemu dump > showing this capability is missing. > > Once there will be a released or in development qemu version that > supports this please add a capability dump ( see > tests/qemucapabilitiesdata/README.rst ) with the 'tdx' variant. A > variant is needed because I don't have hardware supporting tdx so I > can't be updating those on the main variant. The core TDX code was merged in QEMU two weeks ago ish, and the quote generator extra fature needed by this patch series merged a few days ago. Soft feature freeze for QEMU 10.1 will be July 15th, release around end of august With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Wed, Jun 25, 2025 at 12:50:51 +0100, Daniel P. Berrangé wrote: > On Wed, Jun 25, 2025 at 01:19:34PM +0200, Peter Krempa wrote: > > On Wed, Jun 25, 2025 at 17:45:15 +0800, Zhenzhong Duan wrote: > > > QEMU_CAPS_TDX_GUEST set means TDX supported with this QEMU. > > > > > > Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> > > > Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> > > > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> > > > --- > > > src/qemu/qemu_capabilities.c | 2 ++ > > > src/qemu/qemu_capabilities.h | 1 + > > > 2 files changed, 3 insertions(+) > > > > I presume that this is not yet supported by qemu since a qemu dump > > showing this capability is missing. > > > > Once there will be a released or in development qemu version that > > supports this please add a capability dump ( see > > tests/qemucapabilitiesdata/README.rst ) with the 'tdx' variant. A > > variant is needed because I don't have hardware supporting tdx so I > > can't be updating those on the main variant. > > The core TDX code was merged in QEMU two weeks ago ish, and the quote > generator extra fature needed by this patch series merged a few days > ago. Soft feature freeze for QEMU 10.1 will be July 15th, release > around end of august This series does actually have the capability dump based on the upstream qemu code but it's at the end of the series.
On Wed, Jun 25, 2025 at 13:19:34 +0200, Peter Krempa via Devel wrote: > On Wed, Jun 25, 2025 at 17:45:15 +0800, Zhenzhong Duan wrote: > > QEMU_CAPS_TDX_GUEST set means TDX supported with this QEMU. > > > > Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> > > Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> > > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> > > --- > > src/qemu/qemu_capabilities.c | 2 ++ > > src/qemu/qemu_capabilities.h | 1 + > > 2 files changed, 3 insertions(+) > > I presume that this is not yet supported by qemu since a qemu dump > showing this capability is missing. > > Once there will be a released or in development qemu version that > supports this please add a capability dump ( see > tests/qemucapabilitiesdata/README.rst ) with the 'tdx' variant. A > variant is needed because I don't have hardware supporting tdx so I > can't be updating those on the main variant. I noticed that you did add a dump later on, any reason why it's not added before this patch so that this patch will show that the detection works?
>-----Original Message----- >From: Peter Krempa <pkrempa@redhat.com> >Subject: Re: [PATCH v2 03/21] qemu: Add TDX capability > >On Wed, Jun 25, 2025 at 13:19:34 +0200, Peter Krempa via Devel wrote: >> On Wed, Jun 25, 2025 at 17:45:15 +0800, Zhenzhong Duan wrote: >> > QEMU_CAPS_TDX_GUEST set means TDX supported with this QEMU. >> > >> > Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> >> > Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> >> > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> >> > --- >> > src/qemu/qemu_capabilities.c | 2 ++ >> > src/qemu/qemu_capabilities.h | 1 + >> > 2 files changed, 3 insertions(+) >> >> I presume that this is not yet supported by qemu since a qemu dump >> showing this capability is missing. >> >> Once there will be a released or in development qemu version that >> supports this please add a capability dump ( see >> tests/qemucapabilitiesdata/README.rst ) with the 'tdx' variant. A >> variant is needed because I don't have hardware supporting tdx so I >> can't be updating those on the main variant. > >I noticed that you did add a dump later on, any reason why it's not >added before this patch so that this patch will show that the detection >works? I don't understand this rule. For example, in linux kernel patchset, selftests are always at the end of the whole series. Adding dump for a feature before the commit introducing the feature will make the 'ninja test' fail on the commit adding the dump. Don't we need to ensure each commit having 'ninja test' succeed? About your suggestion, do you mean moving both qemucapabilitiestest and qemuxmlconftest dumps(patch18-20) before this patch? Or only patch18-19? Thanks Zhenzhong
On Fri, Jun 27, 2025 at 07:42:48 +0000, Duan, Zhenzhong wrote: > > > >-----Original Message----- > >From: Peter Krempa <pkrempa@redhat.com> > >Subject: Re: [PATCH v2 03/21] qemu: Add TDX capability > > > >On Wed, Jun 25, 2025 at 13:19:34 +0200, Peter Krempa via Devel wrote: > >> On Wed, Jun 25, 2025 at 17:45:15 +0800, Zhenzhong Duan wrote: > >> > QEMU_CAPS_TDX_GUEST set means TDX supported with this QEMU. > >> > > >> > Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> > >> > Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> > >> > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> > >> > --- > >> > src/qemu/qemu_capabilities.c | 2 ++ > >> > src/qemu/qemu_capabilities.h | 1 + > >> > 2 files changed, 3 insertions(+) > >> > >> I presume that this is not yet supported by qemu since a qemu dump > >> showing this capability is missing. > >> > >> Once there will be a released or in development qemu version that > >> supports this please add a capability dump ( see > >> tests/qemucapabilitiesdata/README.rst ) with the 'tdx' variant. A > >> variant is needed because I don't have hardware supporting tdx so I > >> can't be updating those on the main variant. > > > >I noticed that you did add a dump later on, any reason why it's not > >added before this patch so that this patch will show that the detection > >works? > > I don't understand this rule. For example, in linux kernel patchset, selftests > are always at the end of the whole series. > > Adding dump for a feature before the commit introducing the feature will > make the 'ninja test' fail on the commit adding the dump. Well, it will not fail if the output files match the state without the feature. The patch adding the capability will then also need to include changes to the output files to correspond with the feature now existing. >Don't we need to > ensure each commit having 'ninja test' succeed? Yes all tests must pass after each commit. > About your suggestion, do you mean moving both qemucapabilitiestest and > qemuxmlconftest dumps(patch18-20) before this patch? Or only patch18-19? The important part is that we do have tests for this. Thus I will not require that you move the tests. Usually we include capability dumps early, so that the patches adding the flags show which capability dumps enable the new flags. This would mean moving patches 18 and 19 earlier. Thus if you're okay with fixing the two instances of test output file changes that will be necessary that is also an option. The patch adding domain XML tests needs to be still kept at the end.
>-----Original Message----- >From: Peter Krempa <pkrempa@redhat.com> >Subject: Re: [PATCH v2 03/21] qemu: Add TDX capability > >On Fri, Jun 27, 2025 at 07:42:48 +0000, Duan, Zhenzhong wrote: >> >> >> >-----Original Message----- >> >From: Peter Krempa <pkrempa@redhat.com> >> >Subject: Re: [PATCH v2 03/21] qemu: Add TDX capability >> > >> >On Wed, Jun 25, 2025 at 13:19:34 +0200, Peter Krempa via Devel wrote: >> >> On Wed, Jun 25, 2025 at 17:45:15 +0800, Zhenzhong Duan wrote: >> >> > QEMU_CAPS_TDX_GUEST set means TDX supported with this QEMU. >> >> > >> >> > Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> >> >> > Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> >> >> > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> >> >> > --- >> >> > src/qemu/qemu_capabilities.c | 2 ++ >> >> > src/qemu/qemu_capabilities.h | 1 + >> >> > 2 files changed, 3 insertions(+) >> >> >> >> I presume that this is not yet supported by qemu since a qemu dump >> >> showing this capability is missing. >> >> >> >> Once there will be a released or in development qemu version that >> >> supports this please add a capability dump ( see >> >> tests/qemucapabilitiesdata/README.rst ) with the 'tdx' variant. A >> >> variant is needed because I don't have hardware supporting tdx so I >> >> can't be updating those on the main variant. >> > >> >I noticed that you did add a dump later on, any reason why it's not >> >added before this patch so that this patch will show that the detection >> >works? >> >> I don't understand this rule. For example, in linux kernel patchset, selftests >> are always at the end of the whole series. >> >> Adding dump for a feature before the commit introducing the feature will >> make the 'ninja test' fail on the commit adding the dump. > >Well, it will not fail if the output files match the state without the >feature. The patch adding the capability will then also need to include >changes to the output files to correspond with the feature now existing. Get your point, that does make sense. Will do. > >>Don't we need to >> ensure each commit having 'ninja test' succeed? > >Yes all tests must pass after each commit. > >> About your suggestion, do you mean moving both qemucapabilitiestest and >> qemuxmlconftest dumps(patch18-20) before this patch? Or only >patch18-19? > >The important part is that we do have tests for this. Thus I will not >require that you move the tests. > >Usually we include capability dumps early, so that the patches adding >the flags show which capability dumps enable the new flags. This would >mean moving patches 18 and 19 earlier. Thus if you're okay with fixing >the two instances of test output file changes that will be necessary >that is also an option. Will do. Thanks Zhenzhong > >The patch adding domain XML tests needs to be still kept at the end.
© 2016 - 2025 Red Hat, Inc.