From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UK97O-00005t-VX for qemu-devel@nongnu.org; Mon, 25 Mar 2013 11:15:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UK97H-0006A1-R4 for qemu-devel@nongnu.org; Mon, 25 Mar 2013 11:15:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60787) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UK97H-00069h-IU for qemu-devel@nongnu.org; Mon, 25 Mar 2013 11:15:19 -0400 Date: Mon, 25 Mar 2013 16:15:15 +0100 From: Igor Mammedov Message-ID: <20130325161515.06a2970b@nial.usersys.redhat.com> In-Reply-To: <51501B58.1060300@suse.de> References: <1362017554-1260-1-git-send-email-hpa@zytor.com> <51501B58.1060300@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH 1/3] target-i386: Add 486sx, old486, and old486sx CPU models List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?ISO-8859-1?B?RuRyYmVy?= Cc: Orit Wasserman , Eduardo Habkost , qemu-devel@nongnu.org, Anthony Liguori , "H. Peter Anvin" On Mon, 25 Mar 2013 10:39:36 +0100 Andreas F=E4rber wrote: > Am 28.02.2013 03:12, schrieb H. Peter Anvin: > > From: "H. Peter Anvin" > >=20 > > 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. > >=20 > > 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. > >=20 > > This also changes the classic 486 model number to 8 (DX4) which > > matches the feature set presented. > >=20 > > Signed-off-by: H. Peter Anvin > > --- > > 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(-) > >=20 > > 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; > > =20 > > -#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_API= C) > > #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[] =3D { > > .model_id =3D "Genuine Intel(R) CPU T2600 @ 2.16GHz= ", > > }, > > { > > + .name =3D "old486", > > + .level =3D 0, > > + .vendor =3D CPUID_VENDOR_INTEL, > > + .family =3D 4, > > + .model =3D 1, > > + .stepping =3D 0, > > + .features =3D OLD_I486_FEATURES, > > + .xlevel =3D 0, > > + }, > > + { > > + .name =3D "old486sx", > > + .level =3D 0, > > + .vendor =3D CPUID_VENDOR_INTEL, > > + .family =3D 4, > > + .model =3D 2, > > + .stepping =3D 0, > > + .features =3D OLD_I486SX_FEATURES, > > + .xlevel =3D 0, > > + }, > > + { > > .name =3D "486", > > .level =3D 1, > > .vendor =3D CPUID_VENDOR_INTEL, > > .family =3D 4, > > - .model =3D 0, > > + .model =3D 8, >=20 > 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 =3D 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? >=20 > > .stepping =3D 0, > > .features =3D I486_FEATURES, > > .xlevel =3D 0, > > },