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

[Gabriel L. Somlo]

On Mon, Jan 20, 2014 at 10:31:56PM +0200, Michael S. Tsirkin wrote:
> > And later:
> > 
> >                 Device (HPET) {
> >                     ...
> >                     Method (_STA, 0, NotSerialized) {
> >                         If (LGreaterEqual (OSYS, 0x07D1)) {
> >                             If (HPAE) {
> >                                 Return (0x0F)
> >                             }
> >                         } Else {
> >                             If (HPAE) {
> 
> and where does HPAE come from?

e.g, on the MBP2,2:

    OperationRegion (RCRB, SystemMemory, 0xFED1C000, 0x4000)
    Field (RCRB, DWordAcc, Lock, Preserve)
    {
        Offset (0x1000),
        Offset (0x3000),
        Offset (0x3404),
        HPAS,   2,
            ,   5,
        HPAE,   1,
        ...
    }

i.e., I think it's something similar to how VEND and PRD are
checked in HPET._STA on qemu and seabios to decide whether to
return 0x00 or 0x0F.

> For example, this msdn article at microsoft.com:
> http://msdn.microsoft.com/en-us/library/windows/hardware/gg463275.aspx
> "How to Identify the Windows Version in ACPI by Using _OSI"
> 
> at the end it states:
>       the operating system makes features available based on the
>       string argument to the _OSI method.

The full text of that goes:

 "Implementation Note
  Place the routine that identifies the operating system in an _INI method
  under the \_SB scope so that _OSI can run as early as possible. This
  placement is important because the operating system makes features
  available based on the string argument to the _OSI method."

It all depends on what the document's author meant by "the operating
system" which "makes features available". Because somewhere earlier in
the document they say:

 "Recent versions of the ACPI spec have extended the use cases of
  the _OSI method beyond host operating system version identification.
  However, Windows supports _OSI only for the use of identifying the host
  version of Windows that is running on the system."

So my interpretation would be "call _OSI early during some _INI method
under the \_SB scope, so you know how to tweak the various other ACPI
nodes and methods". Kinda like the Apple OSYS example.

So I got curious, and looked through the DSDT.dsl on my other machines.
Both Dells also have \_SB._INI methods which liberally check _OSI, like
e.g. from my Dell R410 server:

        Name (TOOS, 0x00)
        Method (INIC, 0, NotSerialized) {
            If (CondRefOf (_OSI, Local0)) {
                If (\_OSI ("Windows 2001")) {
                    Store (0x05, TOOS)
                }

                ...

                If (\_OSI ("Linux")) {
                    Store (0x01, TOOS)
                }
            } Else {
                Store (\_OS, Local0)
                Store (SCMP (Local0, "Microsoft Windows NT"), Local1)
                If (Not (Local1)) {
                    Store (0x04, TOOS)
                } Else {
                    Store (SCMP (Local0, "Microsoft Windows"), Local2)
                    If (Not (Local2)) {
                        Store (0x02, TOOS)
                    } Else {
                        Store (SCMP (Local0, "Microsoft WindowsME:Millennium    
Edition"), Local3)
                        If (Not (Local3)) {
                            Store (0x03, TOOS)
                        }
                    }
                }
            }
        }

My Dell D630 laptop also does it. I'm wondering if there is any
non-apple, non-dell hardware that does NOT do this. This feels to
me like "circumstantial evidence" in favor of my interpretation
above, but see below...

> 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 a problem per se; just that, being relatively new to ACPI, I wasn't
strongly in favor or against either of the two possible ways to do this.

I didn't even know about _OSI until Paolo mentioned it somewhere earlier
in the conversation, so my only hammer used to be:

  If (CondRefOf(\_SB.PCI0.ISA.SMC))

to determine whether to include IRQNoFlags in HPET._CRS or not. Now that
I know about _OSI, tying the HPET to the SMC feels a bit hacky. Of
course, if you're right and it's bad voodoo to call _OSI, then it may
yet be the lesser of two evils.

It's just that all DSDTs I have access to (apple and dell) already do
call _OSI with impunity, so I'm not sure just how bad the voodoo is...

> > 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).
> 
> They seem to clear this bit for linux?
> No idea why they do this - want to try looking into
> linux source to figure out?

According to the ACPI docs, the bit is labeled "show device in the u/i",
and at least on XP, the only side effect is listing the HPET in the
device tree or not, sort-of like a "hidden bit". I'll check the linux
source to see if anything is done with that bit, and if so, what.

Thanks,
--Gabriel