Re: [patch 0/3] kvm tool: Serial emulation overhaul

[Avi Kivity <avi@redhat.com>]

On 12/13/2011 03:52 PM, Thomas Gleixner wrote:
> On Tue, 13 Dec 2011, Avi Kivity wrote:
>
> > On 12/13/2011 02:59 AM, Thomas Gleixner wrote:
> > 
> > <snip trace>
> > > Why the heck is a paravirtualized guest using an local APIC timer
> > > emulation, instead of a paravirtualized clock event device?
> > >
> > > Just look at the trace. That's insane. We enter the guest for 2us to
> > > come back and handle the APIC_EOI for 11us. Then we go back to the
> > > guest for 9us and spend again 11us for handling a write to APIC_TMICT.
> > >
> > > That's 11us guest vs. 22us host time.
> > 
> > Run your guest with x2apic enabled, the timing will be very different. 
>
> And what magic do I have to use to make that happen other than having
> x2apic support enabled in the kernel? Or do I need a certain kernel
> version for host and guest to make that work?

With qemu, -cpu host or -cpu blah,+x2apic.  kvm-tool does the equivalent
of -cpu host, so I'm surprised it doesn't show up.  x2apic has been
recognized by the guest for a long time (ce69a784; 2.6.32, I'll be
surprised if you have anything older than that on your machine).

Does x2apic show up in your guest's /proc/cpuinfo?

> > The problem with paravirt clockevents is that if/when the APIC becomes
> > virtualized, then guests which were started with the paravirt
> > clockevents don't get accelerated when they are migrated onto newer
> > hardware.  This problem has bitten us several times in the past; if you
> > want to see how it looks when applied on a large scale look at Xen -
> > they have a paravirt-the-fsck-out-of-everything mode and a full virt
> > mode (which should be way faster these days); the two aren't
> > compatible.  Of course back when they started, they didn't have a
> > choice, but we do.
>
> Well, I can see the migration pain for life migration and I agree that
> paravirt the world and some more is a horror as well. Though there is
> a midground between everything and being smart about certain
> aspects. 

Agree, clocksource is one example where the gain exceeds the pain.

> The whole APIC timer calibration and the back and forth
> conversion is definitely nothing which falls into the category of
> smart.

APIC timer calibration is silly but it hasn't proven to be a real-world
problem.

-- 
error compiling committee.c: too many arguments to function