On 5/18/22 09:59, Haibin Huang wrote:
Signed-off-by: Haibin Huang <haibin.huang(a)intel.com>
---
src/conf/domain_capabilities.c | 10 ++++++++++
src/conf/domain_capabilities.h | 13 +++++++++++++
src/libvirt_private.syms | 1 +
3 files changed, 24 insertions(+)
diff --git a/src/conf/domain_capabilities.c b/src/conf/domain_capabilities.c
index 2a888da1a9..d0e863c5cb 100644
--- a/src/conf/domain_capabilities.c
+++ b/src/conf/domain_capabilities.c
@@ -78,6 +78,16 @@ virSEVCapabilitiesFree(virSEVCapability *cap)
}
+void
+virSGXCapabilitiesFree(virSGXCapability *cap)
+{
+ if (!cap)
+ return;
+
+ VIR_FREE(cap);
+}
+
+
static void
virDomainCapsDispose(void *obj)
{
diff --git a/src/conf/domain_capabilities.h b/src/conf/domain_capabilities.h
index f2eed80b15..9be0cff535 100644
--- a/src/conf/domain_capabilities.h
+++ b/src/conf/domain_capabilities.h
@@ -192,6 +192,13 @@ struct _virSEVCapability {
unsigned int max_es_guests;
};
+typedef struct _virSGXCapability virSGXCapability;
+typedef virSGXCapability *virSGXCapabilityPtr;
+struct _virSGXCapability {
+ bool flc;
+ unsigned int epc_size;
So QEMU declares this as uint64. I'm not sure that uint is long enough
to hold all values. But what bothers me more is QAPI declaration
(qapi/misc-target.json):
##
# @SGXInfo:
#
# Information about intel Safe Guard eXtension (SGX) support
#
# Features:
# @deprecated: Member @section-size is deprecated. Use @sections instead.
And looking into commit message that introduce this change:
https://gitlab.com/qemu-project/qemu/-/commit/a66bd91f030827742778a9e0da1...
The "@section-size" will be deprecated in 7.2 version.
Shouldn't we be parsing sections then? I'd rather see us requiring newer
QEMU (7.0 in which @sections member was introduced) than having to
rewrite this again. Then we'll get into tougher situation where we'll
have to support both old and new QEMUs.
Now, looking ad the new @sections member, it captures per-NUMA node
sizes of SGX enclaves. Shouldn't we pass that information to users?
Michal