On Mon, Mar 25, 2013 at 01:45:47PM -0700, H. Peter Anvin wrote: > On 03/25/2013 12:05 PM, Eduardo Habkost wrote: > > On Mon, Mar 25, 2013 at 11:44:30AM -0700, H. Peter Anvin wrote: > >> On 03/25/2013 08:15 AM, Igor Mammedov wrote: > >>>> > >>>> Such changes have been rejected in the past (e.g., n270 Atom). > >>>> I personally wouldn't object to 486 changes, but I guess it should > >>>> rather be handled via Igor's CPU static properties that I have in my > >>>> review queue: The .model value would be set to 8 but the PC machine > >>>> would be changed alongside to set model = 0 for pc-1.4 and earlier. > >>> It doesn't relates to property refactoring nor to slim CPU sub-classes > >>> conversion either. So it could go in independently. > >>> > >>> But is this change safe from migration POV? > >>> > >> > >> Well, given that the CPU model presented is actually closer to a model 8 > >> than a model 0 it probably is... but the real question is what would > >> cause someone to do migration of a 486 CPU model. > >> > >> The n270 issue is problematic, because right now "n270" can't actually > >> run software compiled for N270... > > > > FWIW, I wouldn't mind too much if the maintainers decide to document 486 > > and n270 as "migration-unsafe" and then knowingly break live-migration > > of those CPU models between qemu <= 1.3 and qemu >= 1.4. It's up to the > > maintainers to choose which way to go. > > > > The right thing, of course (and I believe that's where things are going) > is to unwind these descriptions at the time the VM is created; the > migration should implement the machine as it was launched.
This is a possibility, but we are trying to make the CPU code sane and converted to use common QOM/DeviceState infra-structure before doing that. > > If that isn't practical, then the right thing to do is probably to have > some kind of machine description conversion (so, say, "486" can be > converted to "486-1.3" containing the legacy description), but telling > people that -cpu n270 is something other than a real N270 that can't run > N270 software is user-hostile in the extreme. We have considered having versioned CPU model names, and per-machine-tyep aliases (I think I have sent patches to do that a long time ago), but that approach was discarded in favor of the DeviceState static-properties/compat_props mechanism (described below). > > It needs to be possible to fix bugs.... It is possible to fix them today: just write a compat function or add a global variable that is handled by cpu_x86_init(), and call it from the pc-1.3 machine-type init function. See disable_kvm_pv_eoi() and enable_compat_apic_id_mode(), for example. The difference is that this will be much easier once we introduce the static properties: then you just need to add the compat property values to the compat_props field on the machine-type struct. -- Eduardo