From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55455) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5g9Q-0002Hr-9D for qemu-devel@nongnu.org; Tue, 21 Jan 2014 13:34:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5g9L-0000vC-Cy for qemu-devel@nongnu.org; Tue, 21 Jan 2014 13:34:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]:25081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5g9L-0000v0-4G for qemu-devel@nongnu.org; Tue, 21 Jan 2014 13:34:11 -0500 Date: Tue, 21 Jan 2014 20:38:51 +0200 From: "Michael S. Tsirkin" Message-ID: <20140121183851.GA26382@redhat.com> References: <20140120212517.GD18508@ERROL.INI.CMU.EDU> <52DE4CDC.4070501@redhat.com> <20140121110202.GA22693@redhat.com> <52DE5471.5090901@redhat.com> <20140121114454.GC22693@redhat.com> <20140121181101.GB1323@ERROL.INI.CMU.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140121181101.GB1323@ERROL.INI.CMU.EDU> Subject: Re: [Qemu-devel] [PATCH] ACPI: Add IRQ resource to HPET._CRS on Mac OS X List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" Cc: imammedo@redhat.com, agraf@suse.de, lersek@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com On Tue, Jan 21, 2014 at 01:11:01PM -0500, Gabriel L. Somlo wrote: > Apple hardware invariably adds "IRQNoFlags() {0, 8}" to HPET._CRS, > and, at least on piix+smp, an OS X guest will panic unless IRQNoFlags > is present. On the other hand, Windows XP bluescreens whenever > IRQNoFlags is present. This patch conditionally includes IRQNoFlags > only when detecting the presence of an AppleSMC (as a heuristic > predictor for running a Mac OS X guest). Querying _OS and/or _OSI > directly was considered and rejected because such queries MAY NOT > be stateless from the OSPM standpoint, leading to potentially > unpredictable behavior. > > Signed-off-by: Gabriel Somlo Fine with me. Acked-by: Michael S. Tsirkin I'll pick this up if no one complains. > --- > > On Tue, Jan 21, 2014 at 01:38:26PM +0200, Michael S. Tsirkin wrote: > > 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. > > So, after another closer look at the ACPI 5.0 spec, I indeed agree > that OSPM is allowed to maintain and alter state as a consequence of > being asked and replying to an _OSI("foo") query. > > Which IMHO is bathshit insane: As a firmware dev, you CAN'T ask OSPM > a bunch of innocent yes/no questions and be confident it won't go off > doing crazy things just because you asked the wrong question in the > wrong order... :( > > I had a look through the Linux source, and found that: > > 1. The default answer to _OSI("Linux") is "false", as of 2.6.22 > > 2. The value of _OS is "Microsoft Windows NT". Yes, on Linux... > > So, basically, the whole _OS* thing is treated as a joke. Well, not so > much a joke as a plea to the firmware to "Please Stop Trying To Help Me!" :) > > No idea what OS X does, but at this point I think I thoroughly talked > myself out of wanting to use it, and tying HPET._CRS IRQNoFlags to the > return value of SMC._STA sounds like the less insane thing to do :) > > Thanks, > Gabriel > > hw/i386/acpi-dsdt-hpet.dsl | 15 +++++++++++---- > 1 file changed, 11 insertions(+), 4 deletions(-) > > diff --git a/hw/i386/acpi-dsdt-hpet.dsl b/hw/i386/acpi-dsdt-hpet.dsl > index dfde174..bdc1370 100644 > --- a/hw/i386/acpi-dsdt-hpet.dsl > +++ b/hw/i386/acpi-dsdt-hpet.dsl > @@ -38,14 +38,21 @@ Scope(\_SB) { > } > Return (0x0F) > } > - Name(_CRS, ResourceTemplate() { > -#if 0 /* This makes WinXP BSOD for not yet figured reasons. */ > - IRQNoFlags() {2, 8} > -#endif > + Name(RESP, ResourceTemplate() { > Memory32Fixed(ReadOnly, > 0xFED00000, // Address Base > 0x00000400, // Address Length > ) > }) > + Name(RESI, ResourceTemplate() { > + IRQNoFlags() {0, 8} // Mac OS X only > + }) > + Method(_CRS, 0) { > + If (LEqual(\_SB.PCI0.ISA.SMC._STA, 0x0B)) { > + Return (ConcatenateResTemplate(RESP, RESI)) > + } Else { > + Return (RESP) > + } > + } > } > } > -- > 1.8.1.4