[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4EE75FF8.5060208@redhat.com>
Date: Tue, 13 Dec 2011 16:23:52 +0200
From: Avi Kivity <avi@...hat.com>
To: Thomas Gleixner <tglx@...utronix.de>
CC: Ingo Molnar <mingo@...e.hu>, Pekka Enberg <penberg@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Sasha Levin <levinsasha928@...il.com>
Subject: Re: [patch 0/3] kvm tool: Serial emulation overhaul
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists