On Mon, Mar 25, 2013 at 04:15:15PM +0100, Igor Mammedov wrote: > On Mon, 25 Mar 2013 10:39:36 +0100 > Andreas Färber <afaer...@suse.de> wrote: > > > Am 28.02.2013 03:12, schrieb H. Peter Anvin: > > > From: "H. Peter Anvin" <h...@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 <h...@zytor.com> [...] > > > + }, > > > + { > > > .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?
Migration is exactly the reason we can't include this as-is, and where having static properties would be useful. We need to keep model=0 on the pc-1.3 and older machine-types, and set model=8 only on pc-1.4 and newer. With static properties we can simply set it using the compat_props table; without static properties, we need a compatibility function or global variable to enable the model=0 behavior. > > > > > > .stepping = 0, > > > .features = I486_FEATURES, > > > .xlevel = 0, > > > }, -- Eduardo