qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gabriel L. Somlo
Subject: Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP
Date: Mon, 20 Jan 2014 13:54:15 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]