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

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Jan 20, 2014 at 04:25:18PM -0500, Gabriel L. Somlo wrote:
> 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...

Yes, my server boxes don't have any _OSI in the DSDT.
Unlike laptop which really mostly cares about the
windows version that ships with it, these guys
sometimes care about running non windows OS-es.

It actually does call _OSI later, but in a way that has
no effect:
            Method (_STA, 0, NotSerialized)
            {
                Store (\_OS, Local0)
                Mid (Local0, Zero, 0x09, Local1)
                If (LEqual (Local1, "Microsoft"))
                {
                    If (CondRefOf (_OSI, Local2))
                    {
                        If (\_OSI ("Windows 2009"))
                        {
                            Return (0x0F)
                        }
                        Else
                        {
                            Return (Zero)
                        }
                    }
                    Else
                    {
                        Return (Zero)
                    }
                }
                Else
                {
                    Return (0x0F)
                }
            }

So this is a nice trick: it checks
prefix of _OS *then* calls _OSI.

Of course I'm not sure it won't crash if
_OS is shorter than 9 bytes but we can
write this more defensively.

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


So assuming people don't want to tie this to SMC
(which I still like best) second best
I like the idea of looking at the prefix of _OS -
like code above does - then checking _OSI to make sure.
This way this won't affect microsoft or linux guests.
We probably call this in init though.
Could you find out what are _OS values for OSX?


> 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 I trust what firmware developers do.  From what I saw they
basically ship it and then software has to find work arounds.

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