qemu-devel
[Top][All Lists]
Advanced

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

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


From: Gabriel L. Somlo
Subject: Re: [Qemu-devel] [PATCH v6 0/2] apic: bump emulated lapic version to 0x14
Date: Wed, 7 May 2014 10:39:36 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

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 :)

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



reply via email to

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