On Mon, Jan 20, 2014 at 01:16:02PM +0100, Paolo Bonzini wrote: > Il 20/01/2014 13:08, Michael S. Tsirkin ha scritto: > >>> > > I think the hack looking for the SMC device is safer than _OSI: OSPMs > >>> > > are known to do crazy things when they see _OSI, such as assuming they > >>> > > need to try and emulate the OS probed. > > Source for "OSPMs do crazy things when they see _OSI".
After a bit more digging, I believe this has to do with the fact that OSPM is responsible for define _OSI, and referencing it from e.g. the HPET._CRS method when it's NOT defined (e.g. by a misbehaving OSPM) results in all sorts of unpleasantness. In fact, looking on the MacBookPro, we see the following: DefinitionBlock ("dsdt.aml", "DSDT", 1, "APPLE ", "MacBookP", 0x00090001) { ... Field (GNVS, AnyAcc, Lock, Preserve) { OSYS, 16, ... } ... Scope (\_SB) { Method (_INI, 0, NotSerialized) { Store (0x07DC, OSYS) If (CondRefOf (\_OSI, Local0)) { If (_OSI ("Darwin")) { Store (0x2710, OSYS) } If (\_OSI ("Linux")) { Store (0x03E8, OSYS) } If (\_OSI ("Windows 2009")) { Store (0x07D9, OSYS) } If (\_OSI ("Windows 2012")) { Store (0x07DC, OSYS) } } } ... } ... So, basically, they give OSYS a default value, then *if* _OSI is defined by a well-behaved OSPM, they use it to give OSYS a more useful, specific value. CondRefOf is used to avoid a fatal error in case _OSI does not exist. And later: Device (HPET) { Name (_HID, EisaId ("PNP0103")) Name (_CID, EisaId ("PNP0C01")) Name (BUF0, ResourceTemplate () { IRQNoFlags () {0} IRQNoFlags () {8} Memory32Fixed (ReadWrite, 0xFED00000, // Address Base 0x00000400, // Address Length _Y16) }) Method (_STA, 0, NotSerialized) { If (LGreaterEqual (OSYS, 0x07D1)) { If (HPAE) { Return (0x0F) } } Else { If (HPAE) { Return (0x0B) } } Return (0x00) } ... } Which begins to explain why, on the MBP2,2 I didn't see the HPET show up in the XP device tree at all ! :) I.e., I wonder if XP actually defines _OSI (my inner gambling addict says it probably does not). Long story short, we could use CondRefOf as an intermediary wrapper around _OSI to avoid referencing SMC._STA from within HPET.CRS... Not sure we want to "complicate" the rest of the HPET (e.g. return different values for bit2, "show device in acpi u/i" depending on _OSI, the way Apple machines do). Thanks, --Gabriel