On 06/02/2017 07:28 PM, Halil Pasic wrote: [...] > Maybe integrating some of the discussion from above into the commit > message would be helpful.
applied with the following patch description Currently, under z/VM on a 0x2827, QEMU will detect a 0x2828 if no IBC value is provided. QEMU will simply take the last model of that HW generation, which happens to be the BC version. Let's improve our search for that case by selecting the latest CPU definition that matches the CPU type. This for example will avoid detecting an z13 as a z13s. We might still detect a GA2 version on a GA1 system, but as we don't have further information at hand, there isn't too much we can do about it. The alternative of always presenting the oldest GA is not backward compatible, e.g: You're running on 0x2827 GA2. Old QEMU version indicated "0x2828 GA1 == 0x2827 GA2". After you updated QEMU, you suddenly detect "0x2827 GA1". You're previous libvirt guest might suddenly refuse to run. In the end presenting a newer GA level does not matter because: 1: All GAX models share the same base feature set. A GAX++ might support "more features". 2: Without an IBC, the guest can't detect the GA version. If we have no IBC (esp. unblocked_ibc == 0), the IBC we will present to the guest in read_SCP_info() will be 0. The guest will not know which GA version it has. The problem of missing IBC propagates. If we don't have a feature of the GA++ version, also our guest won't have it. So in summary, the guest also has no idea of its GA version. Signed-off-by: David Hildenbrand <da...@redhat.com> Message-Id: <20170531193434.6918-3-da...@redhat.com> Acked-by: Jason J. Herne <jjhe...@linux.vnet.ibm.com> Reviewed-by: Halil Pasic <pa...@linux.vnet.ibm.com> Signed-off-by: Christian Borntraeger <borntrae...@de.ibm.com> [improve patch description by reusing mailing list discussion]
