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

[Michal Prívozník <mprivozn@xxxxxxxxxx>]

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@xxxxxxxxx>
>>
>> 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@xxxxxxxxx>
>> ---
>>  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.

Michal