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

[Thomas Gleixner <tglx@linutronix.de>]

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?

> 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. The whole APIC timer calibration and the back and forth
conversion is definitely nothing which falls into the category of
smart.

Thanks,

	tglx