Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP

[Michael S. Tsirkin]

On Mon, Jan 20, 2014 at 01:54:15PM -0500, Gabriel L. Somlo wrote:
> 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.

No, that's not what I meant.
Responded to the original question with what my
real concern was.

> 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.

Good to know, thanks for the info.

> 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) {

and where does HPAE come from?

>                                 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).

This document says it does:
http://msdn.microsoft.com/library/windows/hardware/gg463275

> Long story short, we could use CondRefOf as an intermediary wrapper
> around _OSI to avoid referencing SMC._STA from within HPET.CRS...

I'm not sure why it's a problem to refer to SMC._STA
but if it is, we can just patch in another variable
in the HPET scope instead of _OSI.

> 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

They seem to clear this bit for linux?
No idea why they do this - want to try looking into
linux source to figure out?

-- 
MST