On Wed, May 07, 2014 at 10:39:36AM -0400, Gabriel L. Somlo wrote: > On Wed, May 07, 2014 at 05:02:42PM +0300, Michael S. Tsirkin wrote: > > > 2. e1000 flakiness: > > > > > > - link negotiation is flaky (I have a patch, but was told > > > and agree that it morally belongs in the BIOS layer) > > > > Could you remind me what the issue and the patch are? > > See: > > http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg01046.html > > and the thread of messages around it. > > > > - Mavericks doesn't like the current e1000 model > > > (E1000_DEV_ID_82540EM); there was a patch sent to the list > > > to allow selecting among different e1000 models, I think > > > it was: > > > > > > http://lists.nongnu.org/archive/html/qemu-devel/2014-02/msg04411.html > > > > > > Mavericks likes E1000_DEV_ID_82545EM_COPPER, but Windows > > > won't work with that, so picking which model to use from > > > the command line would be nice. The patch seems abandoned > > > at this point, so I might contact the author and ask if > > > he minds me picking it up and continuing to polish it until > > > it's acceptable :) > > > > Yay, please do that! > > OK, seems like the low hanging fruit right now :) > > > > - virtio-net works with an "aftermarket" driver, verified to > > > work both in MountainLion and Mavericks. It's what I'm using > > > right now. > > > > > > AFAIK, that's everything :) > > > > For older OSX we need the mwait nop hack right? > > http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/kvm-mwait-nop-20140205.patch > > So, the "path of least resistance", in increasing order of > "resistance" :) would be: > > 1. On the guest: > > rm -rf System/Library/Extensions/AppleIntelCPUPowerManagement.kext > > This switches the guest back to using "hlt"-based idle. Of course, > you need to do something about monitor/mwait to get the guest up > and running long enough to remove the monitor/mwait based idle kext, > (see below) :) > > 2. Emulate monitor and mwait as "nop", but continue to claim they are > not supported via CPUID. That's the patch you cited. Not sure > though whether that sort of "undocumented" functionality would be > OK with the KVM crowd, though :)
I'd go for this one. It seems unlikely a guest wants to get an exception intentionally. Paolo? > 3. Emulate monitor and mwait (at page-size granularity) by > write-protecting a MONITORed page and triggering MWAITs from > the ensuing write fault handler: > > http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/kvm-mwait-emu-20140205.patch > > This latter patch is still (pre-)alpha, and was really flaky last > time I played with it. I also don't have a good intuition about how > (in-)elegant and (un-)acceptable a hack like this would be for KVM :) > > Given that it's only a problem for OS X 10.7 and older, my intuition > tells me the "bang per buck" is not very good, regardless of how cool > I personally think messing around with the guts of KVM might be :) :) > > Thanks, > --Gabriel
