Re: [PATCH RFC 0/1] s390x CPU Model Feature Deprecation
>> 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