From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60354) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5LRK-0001C5-G6 for qemu-devel@nongnu.org; Mon, 20 Jan 2014 15:27:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5LRE-0004oL-CG for qemu-devel@nongnu.org; Mon, 20 Jan 2014 15:27:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34860) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5LRE-0004oA-3e for qemu-devel@nongnu.org; Mon, 20 Jan 2014 15:27:16 -0500 Date: Mon, 20 Jan 2014 22:31:56 +0200 From: "Michael S. Tsirkin" Message-ID: <20140120203156.GB14528@redhat.com> References: <20140110171311.02e71f62@nial.usersys.redhat.com> <20140117211015.GB18752@ERROL.INI.CMU.EDU> <20140120115850.GA29985@redhat.com> <52DD0F3E.5010903@redhat.com> <20140120120842.GA31500@redhat.com> <52DD1382.3080607@redhat.com> <20140120185414.GC18508@ERROL.INI.CMU.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140120185414.GC18508@ERROL.INI.CMU.EDU> Subject: Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" Cc: Paolo Bonzini , agraf@suse.de, lersek@redhat.com, qemu-devel@nongnu.org, imammedo@redhat.com 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