Re: [Qemu-devel] [PATCH v6 0/2] apic: bump emulated lapic version to 0x14

["Michael S. Tsirkin" <mst@redhat.com>]

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