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 <so...@cmu.edu>
Fine with me.
Acked-by: Michael S. Tsirkin <m...@redhat.com>
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
