[PATCH RFC 0/1] s390x CPU Model Feature Deprecation

[David Hildenbrand]

>>> From what I understand:
>>>
>>> QEMU
>>>  - add a "deprecated-features" feature group (more-or-less David's code)
>>>
>>> libvirt
>>>  - recognize a new model name "host-recommended"
>>>  - query QEMU for host-model + deprecated-features and cache it in caps
>>> file (something like <hostRecCpu>)
>>>  - when guest is defined with "host-recommended", pull <hostRecCPU> from
>>> caps when guest is started (similar to how host-model works today)
>>>
>>> If this is sufficient, then I can then get to work on this.
>>>
>>> My question is what would be the best way to include the deprecated
>>> features when calculating a baseline or comparison. Both work with the
>>> host-model and may no longer present an accurate result. Say, for
>>> example, we baseline a z15 with a gen17 (which will outright not support
>>> CSSKE). With today's implementation, this might result in a ridiculously
>>> old CPU model which also does not support CSSKE. The ideal response
>>> would be a z15 - deprecated features (i.e. host-recommended on a z15),
>>> but we'd need a way to flag to QEMU that we want to exclude the
>>> deprecated features. Or am I totally wrong about this?
>>
>> For baselining, it would be reasonable to always disable deprecated
>> features, and to ignore them during the model selection. Should be
>> fairly easy to implement, let me know if you need any pointers.
>>
> 
> Thanks David. I'll take a look when I can. I may not be very active this
> week due to personal items, but intend to knock this out as soon as
> things settle down on my end.

No need to rush :)

> 
>> I *assume* that for comparison there is nothing to do.
>>
> 
> I think you're right, at least on QEMU's end.
> 
> For libvirt, IIRC, comparison will compare the CPU model cached under
> the hostCPU tag to whatever is in the XML. If comparing, say, a gen17
> host (no csske support) with a gen15 XML, the result should come up as
> "incompatible". To a user, they may think "what the heck, shouldn't old
> gen run on new gen?"

I assume you mean an expanded host model on a z15 that still shows
"csske=true". And it would be correct: the deprecated feature still
around on the older machine (indicated in the host model) is not around
on the newer machine (not indicated in the host model). So starting a VM
with the "host-model" on the old machine cannot be migrated to the new
machine. You'd need to start the VM with the new host-TOBENAMED CPU
model. Comparing with that would work as expected, as the deprecated
features would not be included.

> 
> Doesn't the comparison QAPI report which features cause the result of
> "incompatible"? Would it make sense to amend the libvirt API to report
> features causing this issue? I believe this is what the --error flag is
> meant to do, but as far as I know, nothing useful is currently reported.

Most probably it was never implemented on s390x. Makes sense to me.

> 
> Something like this (assume we're a gen17 host, and cpu.xml contains a
> gen15 host-model)
> 
> # virsh hypervisor-cpu-compare cpu.xml --error
> error: Failed to compare hypervisor CPU with cpu.xml
> error: the CPU is incompatible with host CPU
> error: host CPU does not support: csske

I guess instead of "host CPU" you'd want to indicate one of the two CPU
models provided. Not sure how to differentiate them from the XML.


-- 
Thanks,

David / dhildenb