Re: QEMU PIC indirection patch for in-kernel APIC work

["Dor Laor" <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

>But why is it a good thing to do PV drivers in the kernel?  You lose
>flexibility and functionality to gain performance.  Really, it's more
>about there not being good enough userspace interfaces to do network
IO.
>
>>  The lapic/PIC code
>> should also be available in Qemu for OSs that dont have KVM-alike
>> support in the kernel.
>>
>> and while today most of the performance advantages of moving the PIC
>> into the kernel are masked by the high cost of VM exits, in the
future
>> the effect will be more marked, as the relative cost of piggybacking
out
>> to qemu increases.
>>
>> I can see the value in doing certain things in Qemu, but i cannot see
>> _at all_ the value of handling say the PIT in Qemu. Just look at the
>> Qemu PIT/timers code quality in Qemu for a change ... it's a huge
ugly
>> mess of lots of #ifdefs, ineffective handling of /dev/rtc, linear
list
>> walking, signal overhead, etc., etc. All of that resulting in 10-15%
of
>> 'idle' overhead of KVM+qemu when it runs a Linux guest. On the other
>> side, in the kernel it's most natural to do timers and to emulate
>> hardware, because the kernel has _precise_ knowledge about the
>> platform's capabilities.

I think that the pit just need clean, ifdef-less implementation, I can't
believe it adds a bug performance penalty. Actually it is quite simple
to implement dyn-tick in qemu.
The question is after moving the pic,apic,ioapic into the kernel, is it
nicer to re-implement the pit in the kernel or in qemu. I suggest we
start with the first 3 nominees...

>>
>
>Yeah, I think this is a good point.  If we're going to push the APIC
>into the kernel, we might as well put the PIT there too.  The timing
>stuff is an absolute mess in QEMU since it wants to get a fast high res
>clock but isn't aware of things like CPU migration.  I'm pretty sure
>that if you are on an SMP host, some bad things can happen with the
QEMU
>timer code since it relies on the rdtsc.

Btw: KVM support guest rdtsc over physical cpus, I guess it wasn't
enough and the qemu pit side need to do it too.

>
>Regards,
>
>Anthony Liguori
>
>> 	Ingo
>>
>>
>
>
>-----------------------------------------------------------------------
--
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share
>your
>opinions on IT & business topics through brief surveys-and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVD
EV
>_______________________________________________
>kvm-devel mailing list
>kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>https://lists.sourceforge.net/lists/listinfo/kvm-devel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV