[PATCH RFC 1/1] qemu: capabilities: disable csske for host cpu

Christian Borntraeger borntraeger at de.ibm.com
Fri Mar 11 14:52:57 UTC 2022

Am 11.03.22 um 14:08 schrieb Daniel P. Berrangé:
> On Fri, Mar 11, 2022 at 12:37:46PM +0000, Daniel P. Berrangé wrote:
>> On Fri, Mar 11, 2022 at 01:12:35PM +0100, Christian Borntraeger wrote:
>>> Am 11.03.22 um 10:23 schrieb David Hildenbrand:
>>>> On 11.03.22 10:17, Daniel P. Berrangé wrote:
>>>>> On Thu, Mar 10, 2022 at 11:17:38PM -0500, Collin Walling wrote:
>>>>>> CPU models past gen16a will no longer support the csske feature. In
>>>>>> order to secure migration of guests running on machines that still
>>>>>> support this feature to machines that do not, let's disable csske
>>>>>> in the host-model.
>>>> Sorry to say, removing CPU features is a no-go when wanting to guarantee
>>>> forward migration without taking care about CPU model details manually
>>>> and simply using the host model. Self-made HW vendor problem.
>>> And this simply does not reflect reality. Intel and Power have removed TX
>>> for example. We can now sit back and please ourselves how we live in our
>>> world of dreams. Or we can try to define an interface that deals with
>>> reality and actually solves problems.
>> This proposal wouldn't have helped in the case of Intel removing
>> TSX, because it was removed without prior warning in the middle
>> of the product lifecycle. At that time there were already millions
>> of VMs in existance using the removed feature.
>>>>> The problem scenario you describe is the intended semantics of
>>>>> host-model though. It enables all features available in the host
>>>>> that you launched on. It lets you live migrate to a target host
>>>>> with the same, or a greater number of features. If the target has
>>>>> a greater number of features, it should restrict the VM to the
>>>>> subset of features that were present on the original source CPU.
>>>>> If the target has fewer features, then you simply can't live
>>>>> migrate a VM using host-model.
>>>>> To get live migration in both directions across CPUs with differing
>>>>> featuresets, then the VM needs to be configured with a named CPU
>>>>> model that is a subset of both, rather than host-model.
>>>> Right, and cpu-model-baseline does that job for you if you're lazy to
>>>> lookup the proper model.
>>> Yes baseline will work, but this requires tooling like openstack. The normal
>>> user will just use the default and this is host-model.
>>> Let me explain the usecase for this feature. Migration between different versins
>>> baseline: always works
>>> host-passthrough: you get what you deserve
>>> default model: works
>>> We have disabled CSSKE from our default models (-cpu gen15a will not present csske).
>>> So that works as well.
>>> host-model: Also works for all machines that have csske.
>>> Now: Lets say gen17 will no longer support this. That means that we can not migrate
>>> host-model from gen16 or gen15 because those will have csske.
>>> What options do we have? If we disable csske in the host capabilities that would mean
>>> that a host compare against an xml from an older QEMU would fail (even if you move
>>> from gen14 to gen14). So this is not a good option.
>>> By disabling deprecated features ONLY for the _initial_ expansion of model-model, but
>>> keeping it in the host capabilities you can migrate existing guests (with the
>>> feature) as we only disable in the expansion, but manually asking for it still works.
>>> AND it will allow to move this instantiation of the guest to future machines without
>>> the feature. Basically everything works.
>> The change you proposal works functionally, but none the less it is
>> changing the semantics of host-model. It is defined to expose all the
>> features in the host, and the proposal changes yet. If an app actually
>> /wants/ to use the deprecated feature and it exists in the host, then
>> host-model should be allowing that as it does today.
>> The problem scenario you describe is ultimately that OpenStack does
>> not have a future proof default CPU choice. Libvirt and QEMU provide
>> a mechanism for them to pick other CPU models that would address the
>> problem, but they're not using that. The challenge is that OpenStack
>> defaults currently are a zero-interaction thing.
>> They could retain their zero-interaction defaults, if at install time
>> they queried the libvirt capabilities to learn which named CPU models
>> are available, whereupon they could decide to use gen15a.  The main
>> challenge here is that the list of named CPU models is an unordered
>> set, so it is hard to programatically figure out which of the available
>> named CPU models is the newest/best/recommended.
>> IOW, what's missing is a way for apps to easily identify that 'gen15a'
>> is the best CPU to use on the host, without needing human interaction.
> I think this could be solved with a change to query-cpu-definitions
> in QEMU, to add an extra 'recommended: bool' attribute to the
> CpuDefinitionInfo struct.  This would be defined to be only set for
> 1 CPU model in the list, and would reflect the recommended CPU model
> given the current version of QEMU, kernel and hardware. Or we could
> allow 'recommended' to be set for more than 1 CPU, provided we define
> an explicit ordering of returned CPU models.

I like the recommended: bool attribute. It should provide what we need.

Would you then also suggest to use this for host-model or only for a new
type like "host-recommended" ?

> OpenStack can query this when first launching a guest, and remember
> it for that guest on future boots.
> This makes guest robust against QEMU changing its recommendation
> over time. For example, when it became clear that "TSX" was going
> to be removed, QEMU could have switched to recommending one of the
> Intel no-TSX CPU model variants, but existing guests wouldn't be
> affected.

More information about the libvir-list mailing list