[PATCH v1 5/7] qemu_capabilities: Query for Hyper-V Enlightenments

Peter Krempa pkrempa at redhat.com
Tue Jan 3 13:51:20 UTC 2023


On Thu, Dec 22, 2022 at 14:01:41 +0100, Michal Privoznik wrote:
> Now that we have qemuMonitorGetCPUModelExpansion() aware of
> Hyper-V Enlightenments, we can start querying it. Two conditions
> need to be met:
> 
>   1) KVM is in use,
>   2) Arch is either x86 or arm.
> 
> It may look like modifying the first call to
> qemuMonitorGetCPUModelExpansion() inside of
> virQEMUCapsProbeQMPHostCPU() would be sufficient but it is not.
> We really need to ask QEMU for full expansion and the first call
> does not guarantee that.
> 
> For the test data, I've just copied whatever
> 'query-cpu-model-expansion' returned earlier, therefore there are
> no hv-* props. But that's okay - the full expansion is not stored
> in cache (and thus not formatted in
> tests/qemucapabilitiesdata/caps_*.replies files either). This is
> purely runtime thing.

Well, it is okay for test data to not contain real working data, so that
part is okay.

What is not okay is that you don't store it in the caps_*.xml (not
.replies) because in case when you fetch the capabilities from cache and
thus not from a real qemu instance tried with this particular run of
libvirtd/virtqemud the 'fullQEMU' pointer will not be set.

This in turn means that after restart of libvirtd the hyperv data will
be missing.

It's also visible when I've re-generated the capabilities in the tests
with a real qemu run:

I've got plenty HV features ...

$ git show | grep hv-
    hv-expand
+        "hv-passthrough": true
+        "hv-version-id-minor": 0,
+        "hv-xmm-input": true,
+        "hv-frequencies": true,
+        "hv-vendor-id": "Linux KVM Hv",
+        "hv-syndbg": true,
+        "hv-runtime": true,
+        "hv-stimer-direct": true,
+        "hv-relaxed": true,
+        "hv-crash": true,
+        "hv-version-id-sbranch": 0,
+        "hv-version-id-snumber": 0,
+        "hv-evmcs": false,
+        "hv-version-id-spack": 0,
+        "hv-ipi": true,
+        "hv-stimer": true,
+        "x-hv-synic-kvm-only": false,
+        "hv-enforce-cpuid": false,
+        "hv-avic": true,
+        "hv-reset": true,
+        "hv-emsr-bitmap": true,
+        "hv-tlbflush-direct": false,
+        "hv-reenlightenment": true,
+        "hv-apicv": true,
+        "hv-version-id-build": 14393,
+        "hv-version-id-major": 10,
+        "hv-spinlocks": 4095,
+        "hv-passthrough": true,
+        "hv-vapic": true,
+        "x-hv-max-vps": 1024,
+        "hv-vpindex": true,
+        "hv-no-nonarch-coresharing": "off",
+        "hv-synic": true,
+        "hv-time": true,
+        "hv-tlbflush": true,
+        "hv-tlbflush-ext": false,

But the 'domaincapstest' which reads the (caps_*.xml) file as if it were
cached still fills the following capabilities:

diff --git a/tests/domaincapsdata/qemu_8.0.0-q35.x86_64.xml b/tests/domaincapsdata/qemu_8.0.0-q35.x86_64.xml
index efc67b2ef9..eb18b5c696 100644
--- a/tests/domaincapsdata/qemu_8.0.0-q35.x86_64.xml
+++ b/tests/domaincapsdata/qemu_8.0.0-q35.x86_64.xml
@@ -249,5 +249,6 @@
     <backup supported='yes'/>
     <sev supported='no'/>
     <sgx supported='no'/>
+    <hyperv supported='no'/>
   </features>
 </domainCapabilities>
diff --git a/tests/domaincapsdata/qemu_8.0.0-tcg.x86_64.xml b/tests/domaincapsdata/qemu_8.0.0-tcg.x86_64.xml
index d9b092e6fd..471a92693f 100644
--- a/tests/domaincapsdata/qemu_8.0.0-tcg.x86_64.xml
+++ b/tests/domaincapsdata/qemu_8.0.0-tcg.x86_64.xml
@@ -248,5 +248,6 @@
     <backup supported='yes'/>
     <sev supported='no'/>
     <sgx supported='no'/>
+    <hyperv supported='no'/>
   </features>
 </domainCapabilities>
diff --git a/tests/domaincapsdata/qemu_8.0.0.x86_64.xml b/tests/domaincapsdata/qemu_8.0.0.x86_64.xml
index 2b17a409bd..436ca212a8 100644
--- a/tests/domaincapsdata/qemu_8.0.0.x86_64.xml
+++ b/tests/domaincapsdata/qemu_8.0.0.x86_64.xml
@@ -249,5 +249,6 @@
     <backup supported='yes'/>
     <sev supported='no'/>
     <sgx supported='no'/>
+    <hyperv supported='no'/>
   </features>
 </domainCapabilities>




More information about the libvir-list mailing list