qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH] ACPI: Add IRQ resource to HPET._CRS on Mac OS X
Date: Tue, 28 Jan 2014 00:51:40 +0100

On 27.01.2014, at 23:51, Gabriel L. Somlo <address@hidden> wrote:

> On Sat, Jan 25, 2014 at 10:08:37AM +0100, Alexander Graf wrote:
>>> From a cursory pass through the Chameleon source, I don't think so.
>> Ok :). I only barely remember what Chameleon did on top of the normal
>> Apple BIOS bootloader.
> 
> I'll start poking at it to find out exactly what it does, but it
> appears to only allow the option of a full DSDT replacement via a
> supplied AML file, but doesn't seem to *edit* the default DSDT in
> any way.
> 
>>> Currently, I have SnowLeopard, Lion, and MountainLion working fine.
>>> MountainLion needs the 10.8.5 installer (10.8.0 installer hangs at
>>> boot).
>>> 
>>> Mavericks 10.9.0 installer boots and works fine, but the resulting hdd
>>> image, while bootable, hangs during boot. I want to try the latest
>>> Mavericks installer before moving on to isolate the bits of Chameleon
>>> magic that are relevant to us (QEMU+KVM).
>>> 
>>> That's about where things are right now :)
>> 
>> Nice progress :). Thanks a lot for taking care of all this!
> 
> So, most current state of affairs with most up-to-date releases
> of each of 10.[6..9]:
> 
> - IRQNoFlags hack only needed on SnowLeopard with PIIX *and* SMP;
>  every other version works fine without it in all combinations, at
>  the currently most up to date point release.
> 
> - I can boot everything from SnowLeopard all the way to Mavericks
>  using Chameleon (svn 2345 or later), with the following caveats:
> 
>    - MountainLion only boots and installs from later releases
>      (I tried. 10.8.0 and it didn't boot, then 10.8.5 and it works
>      flawlessly -- no idea where between the two it started working)
> 
>    - e1000 link negotiation patch needed on 10.6 and 10.7 (see
>      http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg01046.html)
> 
>        - on 10.8 without that patch link is still reported as "down"
>          but packets do make it in and out of the guest successfully
>          anyway !!! :)
> 
>    - on Mavericks, the e1000 pci card doesn't work. In "System
>      Information", under "Hardware", I get nothing under "Ethernet
>      Cards", and "ethernet controller, pci slot 2, driver_installed=No"
>      under "PCI Cards". On MountainLion and earlier, "Driver Installed"
>      used to be "Yes", and the card used to show up under Ethernet Cards
>      as well, using the AppleIntel8254XEthernet.kext. This kext is
>      present on Mavericks as well, but doesn't seem to work there.

Does ioreg give any hints?

> 
>    - Once the "firstboot" portion of Mavericks is complete, I can
>      boot it UP or SMP, PIIX or Q35, and it works OK (modulo the
>      problem with not recognizing the e1000 network card). But after
>      a fresh install from media, the first boot only happens with
>      SMP. First boot *without* SMP hangs immediately before the
>      GUI would have been started.

Odd. I would've expected the reverse :).

> Any ideas (especially related to the e1000 weirdness) much
> appreciated!
> 
> Thanks,
> --Gabriel
> 
> PS. For *all* OS X versions mentioned above, I'm patching kvm to treat
>  monitor and mwait as NOP, and also the mysterious "ioapic polarity"

You only need to mark the mwait'ed pages as trapping and wake up the other cpu 
when it hits ;). "only".

>  patch without which OS X hangs at boot with "still waiting for root
>  device". I'll dig at this one a bit too, over the next couple of

IIRC the problem is that in our DSDT we declare the PCI interrupts as high 
triggered while PCI is defined to be low triggered. Linux and Windows adhere to 
PCI more than ACPI, but OSX seems to configure the IOAPIC accordingly and 
doesn't see the interrupt because of that.


Alex

>  weeks, then open up a thread about it on the KVM list, where it
>  belongs...
> 
> --- a/virt/kvm/ioapic.c
> +++ b/virt/kvm/ioapic.c
> @@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int 
> irq, int irq_source_id,
>       irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
>                                        irq_source_id, level);
>       entry = ioapic->redirtbl[irq];
> -     irq_level ^= entry.fields.polarity;
>       if (!irq_level) {
>               ioapic->irr &= ~mask;
>               ret = 1;
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]