From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8Vxh-0001M6-TT for qemu-devel@nongnu.org; Wed, 29 Jan 2014 09:17:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W8Vxb-0005QG-Sp for qemu-devel@nongnu.org; Wed, 29 Jan 2014 09:17:53 -0500 Received: from cantor2.suse.de ([195.135.220.15]:35283 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8Vxb-0005Ps-H6 for qemu-devel@nongnu.org; Wed, 29 Jan 2014 09:17:47 -0500 Message-ID: <52E90D87.4010606@suse.de> Date: Wed, 29 Jan 2014 15:17:43 +0100 From: Alexander Graf MIME-Version: 1.0 References: <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> <20140128164536.GB29329@ERROL.INI.CMU.EDU> In-Reply-To: <20140128164536.GB29329@ERROL.INI.CMU.EDU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] OSX guest support review 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 01/28/2014 05:45 PM, Gabriel L. Somlo wrote: > On Tue, Jan 28, 2014 at 12:51:40AM +0100, Alexander Graf wrote: >> On 27.01.2014, at 23:51, Gabriel L. Somlo wrote: >>> - 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? > Nothing interesting as far as my semi-trained eye could tell, but I've > included a trimmed-down excerpt from both MountainLion (where it works) > and from Mavericks (where it doesn't) at the very end of this email. > >>> 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". > I already have a patch doing just that, which works reliably on UP, > and sometimes even on "-smp 2" :) But that's a post for the KVM list, > as soon as I re-acquaint myself with the parts of KVM I'm touching > (see www.contrib.andrew.cmu.edu/~somlo/OSXKVM/kvm-mwait-emu-20131213.patch > if you're curious). Just emulating monitor/mwait as NOP works 100% of > the time (and is 100% correct, at the expense of being 100% wasteful > of host CPU cycles). But it allows me to focus on the other moving parts > for now :) Heh, sure :) > >>> 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. > I remember you telling me a bit of that back when I first started. > > Do you belive there's a chance we can work around this by just tweaking > ACPI on the QEMU side, and thus eliminate the need for a KVM patch ? Yes, that's what I was hoping. What does the IRQ link property look like on a real Mac? We define PCI IRQ links as 254 Name(_PRS, ResourceTemplate() { \ 255 Interrupt(, Level, ActiveHigh, Shared) { \ 256 5, 10, 11 \ 257 } \ 258 }) \ Have you tried to change this to ActiveLow? > > Thanks much, > --Gabriel > > > > PS. And now the ioreg output, starting with the working one I agree. I don't see anything particularly different between the two that wouldn't be explained by the missing driver bind. You could try to boot with debug flags enabled (-v debug=0xff io=0xffff) and check whether the probe failed or maybe didn't get triggered at all. Alex