LP1839065 - power8 machines need FW update or qemu/libvirt code - cap-cfpc=broken

[bugproxy]

== Comment: #0 - Michael Ranweiler <email address hidden> - 2019-08-19 00:03:36 ==
I just tried (first time for a while) a very recent qemu on a power8 machine.

I ran into this:
qemu-system-ppc64le: Requested safe cache capability level not supported by kvm, try cap-cfpc=broken

Now I wonder, do we "just" need a FW update for the scope of spectre/meltdown&co.
Or does the qemu actually need extra pacthes to work well again with power8 machines?

Steps to reproduce:
- power8 machine
- install eoan (qemu 4.0)
- try to start a KVM guest

Current vulnerabilities as reported by the kernel:
/sys/devices/system/cpu/vulnerabilities/l1tf
Not affected
/sys/devices/system/cpu/vulnerabilities/mds
Not affected
/sys/devices/system/cpu/vulnerabilities/meltdown
Mitigation: RFI Flush
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
Mitigation: Kernel entry/exit barrier (hwsync)
/sys/devices/system/cpu/vulnerabilities/spectre_v1
Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2
Vulnerable

Caps and Domcaps:
$ virsh capabilities
<capabilities>

  <host>
    <uuid>de868906-44ea-4d29-85dd-138f8daf2d49</uuid>
    <cpu>
      <arch>ppc64le</arch>
      <model>POWER8</model>
      <vendor>IBM</vendor>
      <topology sockets='1' cores='5' threads='8'/>
      <pages unit='KiB' size='64'/>
      <pages unit='KiB' size='16384'/>
      <pages unit='KiB' size='16777216'/>
    </cpu>
    <power_management>
      <suspend_mem/>
    </power_management>
    <iommu support='yes'/>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>tcp</uri_transport>
        <uri_transport>rdma</uri_transport>
      </uri_transports>
    </migration_features>
    <topology>
...

$ virsh domcapabilities
<domainCapabilities>
  <path>/usr/bin/qemu-system-ppc64</path>
  <domain>kvm</domain>
  <machine>pseries-eoan</machine>
  <arch>ppc64le</arch>
  <vcpu max='1024'/>
  <iothreads supported='yes'/>
  <os supported='yes'>
    <enum name='firmware'/>
    <loader supported='yes'>
      <enum name='type'>
        <value>rom</value>
        <value>pflash</value>
      </enum>
      <enum name='readonly'>
        <value>yes</value>
        <value>no</value>
      </enum>
      <enum name='secure'>
        <value>no</value>
      </enum>
    </loader>
  </os>
  <cpu>
    <mode name='host-passthrough' supported='yes'/>
    <mode name='host-model' supported='yes'>
      <model fallback='allow'>POWER8</model>
      <vendor>IBM</vendor>
    </mode>
    <mode name='custom' supported='no'/>
  </cpu>
...

As a fallback, I haven't foudn the right libvirt'y way to specify cap-cfpc to qemu.
I know we did with HTM but it seems all other controls but HTM got dropped?
=> https://www.redhat.com/archives/libvir-list/2018-March/msg00474.html

Sorry, but I'm lost and trying random optins seems wrong.
I'm sure you run P8 regularly and know what we'd need.
=> how would I get to use a guest on these machines?
Tags: ppc64el reverse-proxy-bugzilla Edit Tag help
Christian Ehrhardt ? (paelzer) wrote on 2019-08-06: #1

I need "-machine pseries-eoan,cap-cfpc=broken,cap-sbbc=broken,cap-ibs=broken" to get further.
So all the list that was discussed back then.
Hopefully this is just a loack of knowledge on my side how to start ppc guests on these machines these days.
Frank Heimes (frank-heimes) on 2019-08-06
tags: added: ppc64el
Changed in ubuntu-power-systems:
importance: Undecided ? High
assignee: nobody ? bugproxy (bugproxy)
Frank Heimes (frank-heimes) on 2019-08-12
tags: added: reverse-proxy-bugzilla

== Comment: #2 - Michael Ranweiler <email address hidden> - 2019-08-19 00:05:28 ==
Please reverse mirror:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1839065

[Frank Heimes (fheimes)]

To summary all information on this topic and to join forces, I'll mark this ticket as a duplicate of this slightly earlier one: LP 1839065

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2020-03-12 03:06 EDT-------
(In reply to comment #6)
> To summary all information on this topic and to join forces, I'll mark this
> ticket as a duplicate of this slightly earlier one: LP 1839065

Can we close this bug? is this bug marked as duplicate of other bug?

[Frank Heimes (fheimes)]

From a Canonical/Ubuntu point of view this is already closed, because of the fact that LP 1839065 is closed. We don't update the status of duplicate bugs like this one.