On Tue, Jun 25, 2019 at 05:13:57PM +0100, Daniel P. Berrangé wrote: > On Tue, Jun 25, 2019 at 02:00:02AM -0300, Eduardo Habkost wrote: > > This series implements basic infrastructure for CPU model > > versioning, as discussed before[1][2][3]. This will finally > > allow us to update CPU models in ways that introduce new software > > or hardware requirements. > > > > My original plan was to use "query-cpu-model-expansion > > mode=static" to resolve aliases, but I dropped that plan because > > it would increase complexity for management software a lot. > > static CPU models are documented as not being affected by the > > machine type and accelerator at all, which would make the > > versioned CPU models very inconvenient to use in the command > > line. e.g.: users would be forced to replace: > > > > -cpu Haswell > > > > with: > > > > -cpu > > Haswell-4.1,+2apic,+monitor,+kvmclock,+kvm-nopiodelay,+kvm-asyncpf,+kvm-steal-time,+kvm-pv-eoi,+kvmclock-stable-bit,+x2apic,-acpi,-monitor,-svm > > > > In the end, making the versioned CPU models static is not a > > requirement at all: what we really need is to drop the > > runnability guarantees from unversioned CPU model names, and > > require management software to resolve the unversioned alias > > before saving the VM configuration. > > > > Guest ABI compatibility and live migration guarantees are going > > to be kept: unversioned CPU models will still be usable with live > > migration. Only runnability guarantees when updating the machine > > type will be dropped. This means unversioned CPU models are > > still reported as migration-safe in query-cpu-definitions. > > I'm having a little bit of a hard time parsing the overall behaviour > from the above description. Let me outline the examples so you can > confirm if I've got it right. > > Lets assume there is a VM configured using "Haswell" > > Today a mgmt app would pass the CPU model name in to QEMU as is, > and thus we get > > $QEMU -machine pc-i440fx-4.0 -cpu Haswell ...more args... > > The semantics of "Haswell" here is going to vary according to > what the machine type pc-i440fx-4.0 customizes wrt Haswell. > > If the config later has the machine type changed to pc-i440fx-4.1 > the semantics of Haswell might change in an arbitrary way. It > might even become unrunnable on the current hardware.
If we follow our deprecation policy, this shouldn't happen until pc-*-4.3. On pc-*-4.1 and pc-*-4.2, I expect "-cpu Haswell" to stay runnable if it's already runnable with pc-*-4.0. This will give libvirt and other management software some time to adapt. CPU model changes that don't affect runnability, though, are already allowed and will still be allowed. > > With the new versioned machine types, the VM config of "Haswell" > would be resolved into some arbitrary versioned machine type > "Haswell-NNN" and thus the mgmt app would launch > > $QEMU -machine pc-i440fx-4.0 -cpu Haswell-NNN ...more args... > > The semantics of "Haswell-NNN" will never change no matter what > the machine type does. Exactly. > > The end user has the option to explicitly give "Haswell-NNN" to > the mgmt app if they know they want that particular variant, and > in this case the mgmt app won't need to resolve anything (or at > least the process of trying to resolve it won't change it). Yes. Management software should see that "Haswell-NNN" has no "alias-of" field, so it doesn't need to be changed. -- Eduardo
