From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35087) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7vy4-0001Zs-E8 for qemu-devel@nongnu.org; Mon, 27 Jan 2014 18:51:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W7vxy-0002zf-2K for qemu-devel@nongnu.org; Mon, 27 Jan 2014 18:51:52 -0500 Received: from cantor2.suse.de ([195.135.220.15]:60440 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7vxx-0002zZ-O9 for qemu-devel@nongnu.org; Mon, 27 Jan 2014 18:51:45 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Alexander Graf In-Reply-To: <20140127225115.GA29329@ERROL.INI.CMU.EDU> Date: Tue, 28 Jan 2014 00:51:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52DE4CDC.4070501@redhat.com> <20140121110202.GA22693@redhat.com> <52DE5471.5090901@redhat.com> <20140121114454.GC22693@redhat.com> <20140121181101.GB1323@ERROL.INI.CMU.EDU> <20140121183851.GA26382@redhat.com> <20140124164608.GB1293@ERROL.INI.CMU.EDU> <20140125000945.GA10357@crash.ini.cmu.edu> <6FAEE645-799D-4535-B568-75AB5E4D206C@suse.de> <20140127225115.GA29329@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" , "pbonzini@redhat.com" , "lersek@redhat.com" , "qemu-devel@nongnu.org" , "Michael S. Tsirkin" On 27.01.2014, at 23:51, Gabriel L. Somlo wrote: > On Sat, Jan 25, 2014 at 10:08:37AM +0100, Alexander Graf wrote: >>> =46rom 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. >=20 > 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. >=20 >>> Currently, I have SnowLeopard, Lion, and MountainLion working fine. >>> MountainLion needs the 10.8.5 installer (10.8.0 installer hangs at >>> boot). >>>=20 >>> 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). >>>=20 >>> That's about where things are right now :) >>=20 >> Nice progress :). Thanks a lot for taking care of all this! >=20 > So, most current state of affairs with most up-to-date releases > of each of 10.[6..9]: >=20 > - 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. >=20 > - I can boot everything from SnowLeopard all the way to Mavericks > using Chameleon (svn 2345 or later), with the following caveats: >=20 > - 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) >=20 > - e1000 link negotiation patch needed on 10.6 and 10.7 (see > = http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg01046.html) >=20 > - 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 !!! :) >=20 > - 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=3DNo" > 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? >=20 > - 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! >=20 > Thanks, > --Gabriel >=20 > 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... >=20 > --- 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 =3D __kvm_irq_line_state(&ioapic->irq_states[irq], > irq_source_id, level); > entry =3D ioapic->redirtbl[irq]; > - irq_level ^=3D entry.fields.polarity; > if (!irq_level) { > ioapic->irr &=3D ~mask; > ret =3D 1; >=20