On Mon, Nov 04, 2024 at 04:10:12PM +0100, Cornelia Huck wrote: > On Mon, Nov 04 2024, Daniel P. Berrangé <berra...@redhat.com> wrote: > > > > > FYI, in x86 target the -cpu command has had a "migratable=bool" property > > for a long time , which defaults to 'true' for 'host' model. This causes > > QEMU to explicitly drop features which would otherwise prevent migration > > between two hosts with identical physical CPUs. > > > > IOW, if there are some bits present in 'host' that cause migration > > problems on Ampere hosts, ideally either QEMU (or KVM kmod) would > > detect them and turn them off automatically if migratable=true is > > set. See commit message in 84f1b92f & 120eee7d1fd for some background > > info > > How does this work for version-sensitive features -- are they always > defaulting to off? How many features are left with that in the end?
Do you mean QEMU versions here ? The non-migratable feature list is just hardcoded in QEMU right now, and there's only 1 of them. eg grep for 'unmigratable_flags' Note, that "migratable" property is not defining a general purpose migration mask between different hw generations. It was specifically blocking just stuff that is known to make migration impossible, even if HW is identical on both sides. > > NB "migratable" is defined in i386 target code today, but conceptually > > we should expand/move that to apply to all targets for consistency, > > even if it is effectively a no-op some targets (eg if they are > > guaranteed migratable out of the box already with '-cpu host'). > > How does this compare to s390x, which defines some migration-safe cpu > models, based upon the different hw generations? If I look at the QEMU > code for x86 and s390x, the s390x approach seems cleaner to me (probably > because it came later, and therefore could start afresh without having > to care for legacy things.) Given that we'll cook up a new model for Arm > migration as well, we might as well start with a clean implementation :) The impression I get (as an distant observer) is that CPUs on s390x in general have less complexity to worry about. A combination of not having a vendor who creates loads off different SKUs for the same CPU model family with slight variations between each, and also not seeming to have a situation where CPU flags a known to disappear (or appear) arbitrarily in microcode updates. The s390x idea of a "migratable" and "non migratable" model for each HW generation is a nice simplification, but I can't see how it could be made to work for x86 when you can't predict ahead of time what features are going to be removed from existing HW definition by the next microcode update, or by the next CPU SKU that removes a feature you had assumed would always be present in a given HW generation. I don't know much about how ARM world works, but having lots of vendors competing with their own custom impls makes me worry complexity will be closer to x86 than to s390. If the ARM specifications define a minimum require featureset for each HW generation, maybe you can define a model based on that ? You might still want to have vendor specific models though, if there are compelling features they expose which are optional, or non-standardized. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
