On Thu, Jan 05, 2023 at 09:34:57 +0100, Michal Privoznik wrote:
> Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
> ---
[....]
> diff --git a/src/conf/domain_capabilities.c b/src/conf/domain_capabilities.c
> index 01714e2270..82432b60a7 100644
> --- a/src/conf/domain_capabilities.c
> +++ b/src/conf/domain_capabilities.c
[...]
> @@ -678,6 +679,22 @@ virDomainCapsFeatureSGXFormat(virBuffer *buf,
> virBufferAddLit(buf, "</sgx>\n");
> }
>
> +static void
> +virDomainCapsFeatureHypervFormat(virBuffer *buf,
> + const virDomainCapsFeatureHyperv *hyperv)
> +{
> + if (!hyperv) {
> + virBufferAddLit(buf, "<hyperv supported='no'/>\n");
> + return;
> + }
Since the hyperv features are properly expanded only starting with
qemu-6.1, but I don't see a way of probing that given qemu does not
support it (hv-passthrough feature is actually supported in qemu-4.2,
but supposedly does nothing when expanding it) this would wrongly report
that hyperv enlightenments are not supported with given qemu which is
not true.
Thus this should most likely completely avoid the 'hyperv' element in
such case as we can't report reliable data and if this is run on x86/arm
then 'no' certainly is a wrong answer as some of the hyperv
enlightenments are supported for a very long time.
'no' is the right answer on other platforms though, but I don't think
that it matters too much.
The same then later comes when qemu doesn't report any of the features,
because we know that on x86 with supported qemu versions that is simply
not true.
> +
> + FORMAT_PROLOGUE(hyperv);
> +
> + ENUM_PROCESS(hyperv, features, virDomainHypervTypeToString);
> +
With appropriate changes:
Reviewed-by: Peter Krempa <pkrempa@xxxxxxxxxx>
