Re: [Qemu-devel] [RFC PATCH 1/3] target-i386: Add 486sx, old486, and old486sx CPU models

[Eduardo Habkost]

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