Bug 1717611

Eduardo/Vitaly,

what kind of information is needed exactly? And do you know where can libvirt get that from?

(In reply to Michal Privoznik from comment #4)
> Eduardo/Vitaly,
> 
> what kind of information is needed exactly? And do you know where can
> libvirt get that from?

I expected hyperv feature flags to be reported through the same mechanism as other CPU features, using query-cpu-model-expansion, with the "max" and "host" CPU models.  "max" tells which features are supported by the host.  "host" tells which features are supported and can be safely enabled by default.

However, it looks like this is not implemented yet.  We need a qemu-kvm BZ for this.  I suggest clearing ITR on this bug by now, until we start working on the qemu-kvm side.

Bulk update: Move RHEL-AV bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Note: QEMU part has landed in 6.1:
https://gitlab.com/qemu-project/qemu/-/commit/071ce4b03becf9e2df6b758fde9609be8ddf56f1
so libvirt can use it with e.g.

query-cpu-model-expansion type=full model={"name":"host","props":{"hv-passthrough":true}}

Adding to plan for 9.2.0. Looks like CNV is also interested in the feature. We need to decide in 9.2 timeframe whether or not to do this or just close.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Patches posted on the list:

https://listman.redhat.com/archives/libvir-list/2022-December/236464.html

v2:

https://listman.redhat.com/archives/libvir-list/2023-January/236613.html

Merged upstream as:

903ea9370d qemu_capabilities: Report Hyper-V Enlightenments in domcapabilities
10f4784864 qemu_capabilities: Query for Hyper-V Enlightenments
ff8731680b qemuMonitorJSONGetCPUModelExpansion: Introduce @hv_passthrough argument
7c12eb2397 qemuMonitorJSONMakeCPUModel: Introduce @hv_passthrough argument
7c1ecfd512 domain_capabilities: Expose Hyper-V Enlightenments
179e45d237 virDomainCapsEnumFormat: Retrun void
a7789d9324 virDomainCapsEnumFormat: Switch to virXMLFormatElement()

v8.10.0-172-g903ea9370d

Pre-verify on upstream libvirt:

# ./builddir/run ./builddir/tools/virsh domcapabilities |grep -A17 '<hyperv'
    <hyperv supported='yes'>
      <enum name='features'>
        <value>relaxed</value>
        <value>vapic</value>
        <value>spinlocks</value>
        <value>vpindex</value>
        <value>runtime</value>
        <value>synic</value>
        <value>stimer</value>
        <value>reset</value>
        <value>vendor_id</value>
        <value>frequencies</value>
        <value>reenlightenment</value>
        <value>tlbflush</value>
        <value>ipi</value>
        <value>avic</value>
      </enum>
    </hyperv>

Verify this bug with libvirt-9.0.0-3.el9.x86_64:

S1: Check hyperv feature support list in domcapabilities output

1.
# virsh domcapabilities |grep -A17 '<hyperv'
    <hyperv supported='yes'>
      <enum name='features'>
        <value>relaxed</value>
        <value>vapic</value>
        <value>spinlocks</value>
        <value>vpindex</value>
        <value>runtime</value>
        <value>synic</value>
        <value>stimer</value>
        <value>reset</value>
        <value>vendor_id</value>
        <value>frequencies</value>
        <value>reenlightenment</value>
        <value>tlbflush</value>
        <value>ipi</value>
        <value>avic</value>
      </enum>
    </hyperv>


2. start a guest use support hyperv features

# virsh edit vm1
...
  <features>
    <acpi/>
    <apic/>
    <hyperv mode='custom'>
      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='4096'/>
      <vpindex state='on'/>
      <runtime state='on'/>
      <synic state='on'/>
      <stimer state='on'>
        <direct state='on'/>
      </stimer>
      <reset state='on'/>
      <vendor_id state='on' value='KVM Hv'/>
      <frequencies state='on'/>
      <reenlightenment state='on'/>
      <tlbflush state='on'/>
      <ipi state='on'/>
      <avic state='on'/>
    </hyperv>
  </features>
...

# virsh start vm1
Domain 'vm1' started

3. add a not support feature and try to start guest

# virsh edit vm1

  <features>
    <acpi/>
    <apic/>
    <hyperv mode='custom'>
      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='4096'/>
      <vpindex state='on'/>
      <runtime state='on'/>
      <synic state='on'/>
      <stimer state='on'>
        <direct state='on'/>
      </stimer>
      <reset state='on'/>
      <vendor_id state='on' value='KVM Hv'/>
      <frequencies state='on'/>
      <reenlightenment state='on'/>
      <tlbflush state='on'/>
      <ipi state='on'/>
      <evmcs state='on'/>     <----- this feature not in support feature list
      <avic state='on'/>
    </hyperv>
  </features>


# virsh start vm1
error: Failed to start domain 'vm1'
error: internal error: qemu unexpectedly closed the monitor: 2023-02-07T09:10:54.933698Z qemu-kvm: Hyper-V enlightened VMCS (hv-evmcs) is not supported by kernel

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (libvirt bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2171