Re: [Qemu-devel] [PATCH] ACPI: Add IRQ resource to HPET._CRS on Mac OS X

["Michael S. Tsirkin" <mst@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 <somlo@cmu.edu>

Fine with me.
Acked-by: Michael S. Tsirkin <mst@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