On Fri, Dec 10, 2021 at 16:47:12 +0000, Daniel P. Berrangé wrote:
> This sev-guest object property indicates whether QEMU should
> expose the kernel, ramdisk, cmdline hashes to the firmware
> for measurement.
>
> The 6.2.0 capabilities are hacked to look as if they were
> generated with sev-guest support.
>
> Reviewed-by: Peter Krempa <pkrempa@xxxxxxxxxx>
> Signed-off-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>
> ---
> src/qemu/qemu_capabilities.c | 8 ++
> src/qemu/qemu_capabilities.h | 1 +
> .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 7 +-
> .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 7 +-
> tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 7 +-
> .../caps_2.12.0.x86_64.replies | 97 ++++++++++++----
> .../caps_3.0.0.x86_64.replies | 97 ++++++++++++----
> .../caps_3.1.0.x86_64.replies | 97 ++++++++++++----
> .../caps_4.0.0.x86_64.replies | 97 ++++++++++++----
> .../caps_4.1.0.x86_64.replies | 89 ++++++++++----
> .../caps_4.2.0.x86_64.replies | 89 ++++++++++----
> .../caps_5.0.0.x86_64.replies | 89 ++++++++++----
> .../caps_5.1.0.x86_64.replies | 89 ++++++++++----
> .../caps_5.2.0.x86_64.replies | 89 ++++++++++----
> .../caps_6.0.0.x86_64.replies | 89 ++++++++++----
> .../caps_6.1.0.x86_64.replies | 89 ++++++++++----
> .../caps_6.2.0.x86_64.replies | 109 ++++++++++++++----
> .../caps_6.2.0.x86_64.xml | 8 ++
> 18 files changed, 895 insertions(+), 263 deletions(-)
>
> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
> index ddd61ecfc9..9553e6e5b8 100644
> --- a/src/qemu/qemu_capabilities.c
> +++ b/src/qemu/qemu_capabilities.c
> @@ -652,6 +652,7 @@ VIR_ENUM_IMPL(virQEMUCaps,
> "device.json", /* QEMU_CAPS_DEVICE_JSON */
> "query-dirty-rate", /* QEMU_CAPS_QUERY_DIRTY_RATE */
> "rbd-encryption", /* QEMU_CAPS_RBD_ENCRYPTION */
> + "sev-guest-kernel-hashes", /* QEMU_CAPS_SEV_GUEST_KERNEL_HASHES */
> );
>
>
> @@ -1718,6 +1719,10 @@ static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsMaxCPU[] = {
> { "migratable", QEMU_CAPS_CPU_MIGRATABLE },
> };
>
> +static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsSEVGuest[] = {
> + { "kernel-hashes", QEMU_CAPS_SEV_GUEST_KERNEL_HASHES },
> +};
> +
> static virQEMUCapsObjectTypeProps virQEMUCapsObjectProps[] = {
> { "memory-backend-file", virQEMUCapsObjectPropsMemoryBackendFile,
> G_N_ELEMENTS(virQEMUCapsObjectPropsMemoryBackendFile),
> @@ -1731,6 +1736,9 @@ static virQEMUCapsObjectTypeProps virQEMUCapsObjectProps[] = {
> { "max-arm-cpu", virQEMUCapsObjectPropsMaxCPU,
> G_N_ELEMENTS(virQEMUCapsObjectPropsMaxCPU),
> QEMU_CAPS_ARM_MAX_CPU },
> + { "sev-guest", virQEMUCapsObjectPropsSEVGuest,
> + G_N_ELEMENTS(virQEMUCapsObjectPropsSEVGuest),
> + QEMU_CAPS_SEV_GUEST },
Actually, when reviewing the last patch I've noticed that 'sev-guest'
which you are querying is actually an '-object', so you don't need any
of this complicated query machinery which modifies all .replies files
but rather it's enough to use the QMP schema query:
Once you add to virQEMUCapsQMPSchemaQueries[] the following line:
{ "object-add/arg-type/+sev-guest/kernel-hashes", QEMU_CAPS_SEV_GUEST_KERNEL_HASHES },
The result is the same information. I actually see you also hacked the
schema to add the field because I presume the QAPI schema validation
failed if that was not the case.
So my R-b applies only on this simpler version as we should not re-query
data we already have from the QMP schema.
