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

[Igor Mammedov <imammedo@redhat.com>]

On Mon, 25 Mar 2013 10:39:36 +0100
Andreas Färber <afaerber@suse.de> wrote:

> Am 28.02.2013 03:12, schrieb H. Peter Anvin:
> > From: "H. Peter Anvin" <hpa@zytor.com>
> > 
> > Add models for 486SX, and pre-CPUID versions of the 486 (DX & SX).
> > Change the model number for the standard 486DX to a model which
> > actually had CPUID.
> > 
> > Note: these models are fairly vestigial, for example most of the FPU
> > operations still work; only F*ST[CS]W have been modified to appear as
> > through there is no FPU.
> > 
> > This also changes the classic 486 model number to 8 (DX4) which
> > matches the feature set presented.
> > 
> > Signed-off-by: H. Peter Anvin <hpa@zytor.com>
> > ---
> >  target-i386/cpu.c         | 39 ++++++++++++++++++++++++++---
> >  target-i386/fpu_helper.c  | 12 +++++++--
> >  target-i386/misc_helper.c | 15 ++++++++----
> >  target-i386/translate.c   | 62
> > +++++++++++++++-------------------------------- 4 files changed, 75
> > insertions(+), 53 deletions(-)
> > 
> > diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> > index aab35c7..a5aad19 100644
> > --- a/target-i386/cpu.c
> > +++ b/target-i386/cpu.c
> > @@ -365,8 +365,11 @@ typedef struct x86_def_t {
> >      uint32_t cpuid_7_0_ebx_features;
> >  } x86_def_t;
> >  
> > -#define I486_FEATURES (CPUID_FP87 | CPUID_VME | CPUID_PSE)
> > -#define PENTIUM_FEATURES (I486_FEATURES | CPUID_DE | CPUID_TSC | \
> > +#define OLD_I486SX_FEATURES 0
> > +#define OLD_I486_FEATURES CPUID_FP87
> > +#define I486SX_FEATURES CPUID_VME /* SX2+ */
> > +#define I486_FEATURES (CPUID_FP87 | CPUID_VME) /* DX4 and some DX2 */
> > +#define PENTIUM_FEATURES (I486_FEATURES | CPUID_PSE | CPUID_DE |
> > CPUID_TSC | \ CPUID_MSR | CPUID_MCE | CPUID_CX8 | CPUID_MMX | CPUID_APIC)
> >  #define PENTIUM2_FEATURES (PENTIUM_FEATURES | CPUID_PAE | CPUID_SEP | \
> >            CPUID_MTRR | CPUID_PGE | CPUID_MCA | CPUID_CMOV | CPUID_PAT | \
> > @@ -535,16 +538,46 @@ static x86_def_t builtin_x86_defs[] = {
> >          .model_id = "Genuine Intel(R) CPU           T2600  @ 2.16GHz",
> >      },
> >      {
> > +        .name = "old486",
> > +        .level = 0,
> > +        .vendor = CPUID_VENDOR_INTEL,
> > +        .family = 4,
> > +        .model = 1,
> > +        .stepping = 0,
> > +        .features = OLD_I486_FEATURES,
> > +        .xlevel = 0,
> > +    },
> > +    {
> > +        .name = "old486sx",
> > +        .level = 0,
> > +        .vendor = CPUID_VENDOR_INTEL,
> > +        .family = 4,
> > +        .model = 2,
> > +        .stepping = 0,
> > +        .features = OLD_I486SX_FEATURES,
> > +        .xlevel = 0,
> > +    },
> > +    {
> >          .name = "486",
> >          .level = 1,
> >          .vendor = CPUID_VENDOR_INTEL,
> >          .family = 4,
> > -        .model = 0,
> > +        .model = 8,
> 
> 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?

> 
> >          .stepping = 0,
> >          .features = I486_FEATURES,
> >          .xlevel = 0,
> >      },