Re: [libvirt][PATCH v11 1/4] qemu: provide support to query the SGX capability

On 5/11/22 18:05, Peter Krempa wrote: > On Tue, May 10, 2022 at 23:11:09 -0700, Lin Yang wrote: >> From: Haibin Huang <haibin.huang(a)intel.com&gt; >> >> QEMU version >= 6.2.0 provides support for creating enclave on >> SGX x86 platform using Software Guard Extensions (SGX) feature. >> This patch adds support to query the SGX capability from the qemu. >> >> Signed-off-by: Haibin Huang <haibin.huang(a)intel.com&gt; >> --- >> src/conf/domain_capabilities.c | 10 ++ >> src/conf/domain_capabilities.h | 13 ++ >> src/libvirt_private.syms | 1 + >> src/qemu/qemu_capabilities.c | 119 ++++++++++++++++++ >> src/qemu/qemu_capabilities.h | 6 + >> src/qemu/qemu_capspriv.h | 4 + >> src/qemu/qemu_monitor.c | 10 ++ >> src/qemu/qemu_monitor.h | 3 + >> src/qemu/qemu_monitor_json.c | 104 +++++++++++++-- >> src/qemu/qemu_monitor_json.h | 9 ++ >> .../caps_6.2.0.x86_64.replies | 22 +++- >> .../caps_6.2.0.x86_64.xml | 5 + >> .../caps_7.0.0.x86_64.replies | 22 +++- >> .../caps_7.0.0.x86_64.xml | 5 + >> 14 files changed, 318 insertions(+), 15 deletions(-) > > This is not a full review. Couple of points: > > 1) Do not mix other changes with adding QEMU_CAPS* stuff > Basically theres waaay too much going on in this patch and it > definitely can be separated into smaller chunks. The QEMU_CAPS is > just one of them. > Separate at least: > - qemu monitor command introduction > - domain capabilities data structs for sgx > - parsing and formatting of the XML > - adding of the QEMU_CAPS_ flag > 2) caps for qemu-7.1 were added very recently > You'll need to fix that one too since you added an extra query. Make > sure that you _don't_ add the faking of SXG into that file, but > rather the error case. My box doesn't support SGX so it will be > overwritten in my next refresh anyways. > > [...] > >> @@ -4706,6 +4805,21 @@ virQEMUCapsFormatSEVInfo(virQEMUCaps *qemuCaps, virBuffer *buf) >> } >> >> >> +static void >> +virQEMUCapsFormatSGXInfo(virQEMUCaps *qemuCaps, >> + virBuffer *buf) >> +{ >> + virSGXCapabilityPtr sgx = virQEMUCapsGetSGXCapabilities(qemuCaps); >> + >> + virBufferAddLit(buf, "<sgx>\n"); >> + virBufferAdjustIndent(buf, 2); >> + virBufferAsprintf(buf, "<flc>%s</flc>\n", sgx->flc ? "yes" : "no"); > > Don't use the ternary operator ('?'), use a full if/else branch instead > or pick a better data structure. I wish our coding style was more forgiving about ternary operator. Because in this specific case we have bad and worse options: 1) Expand to if-else fully: if (boolVar) virBufferAddLit(buf, "<elem>yes</elem>\n"); else virBufferAddLit(buf, "<elem>no</elem>\n"); 2) use virTristateBoolFromBool() virBufferAsprintf(buf, "<elem>%s</elem>\n", virTristateBoolTypeToString(virTristateBoolFromBool(boolVar))); 3) use a temporary variable: char *tmp; if (boolVar) tmp = "yes"; else tmp = "no"; virBufferAsprintf(buf, "<elem>%s</elem>\n", tmp); 4) use virTristateBool: if (virTristateVar) virBudderAsprintf(buf, "<elem>%s</elem>\n", virTristateBoolTypeToSring(virTristateVar)); 5) Introduce a helper, e.g. const char * virYesNoString(bool val) { if (val) return "yes"; return "no"; } virBufferAsprintf(buf, "<elem>%s</elem>\n", virYesNoString(boolVar)); Frankly speaking, I dislike 2) the most, followed by 1, 3, 4, 5. According to my understanding, we discourage use of ternary operator because it can lead to hard to parse expressions. But one can hardly argue about bool ? "yes" : "no" being hard to parse.