Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Gabriel L. Somlo]

Hi Paolo,

On Thu, Jan 09, 2014 at 09:12:22PM +0100, Paolo Bonzini wrote:
> See
> http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg02815.html
> for some ideas.

I remember saving that email for a closer examination after I took
care of the AppleSMC patch, and then I forgot all about it -- thanks
for the reminder !!!

Of the things you mentioned there:

> The IRQNoFlags(){2,8} setting makes sense if the general configuration
> register of the HPET has bits 0..1=1 (HPET enabled = 1 and HPET legacy
> replacement route = 1).
>
> ...
>
>   Method(_CRS, 0) {
>       Store(GCNF, Local0)
>       If (LEqual(LAnd(Local0, 3), 3)) {   // Legacy replacement route
>            ConcatenateResTemplate(RESP, RESI, Local1)

This made no difference. XP worked on piix with up and smp, and OS X
worked everywhere *except* on piix+smp, where it crashed with an HPET
panic.

> (1) Does Mac OS work if you add a _PRS with IRQNoFlags and
> Memory32Fixed, but leave _CRS as it is?

Nope, same exact behavior.

> (2) does it work with -no-hpet?

With "IRQNoFlags(){2, 8}" hardcoded in HPET._CRS, XP appears to work
great if -no-hpet is given. I guess _STA evaluates to 0, so nothing
else matters.

> (3) you could also make that dependent on _OSI("Darwin").

This works, for the same reason as querying SMC._STA (find something
"unique" about OS X and conditionally insert IRQNoFlags(){2, 8}) if
that "something" is detected..


So, we have two solutions that work:

1. hardcode "IRQNoFlags(){2, 8}" and require -no-hpet to prevent XP
   from bluescreening. Basically, this means we don't support XP on
   a VM where HPET is enabled.

2. conditionally insert "IRQNoFlags(){2, 8}" if _OSI("Darwin") returns
   0xFFFFFFFF, which is only necessary if we want to run OS X on piix+smp
   (all other combinations of (piix vs. q35) x (up vs.  smp) work fine
   already).


I still don't get why on real hardware where the HPET has
"IRQNoFlags(){2, 8}" in its _CRS method XP seems to be OK...


Maybe there's some deeper, subtler ACPI "mismatch" we're triggering
here...

Thanks,
--Gabriel