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

[Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>]

* Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:

> > It still exists in userspace.  Having the code duplication 
> > (especially when it's not the same code base) is unfortunate.
> 
> This remains true.

but it's the wrong argument. Of course there's duplicate functionality, 
and that's _good_ because it represents choice. KVM _itself_ is 
duplicate functionality of qemu in a way. So why move the lapic/PIC 
handling to the kernel? Because it's alot cleaner to do device emulation 
there and PV drivers get significantly easier to do. 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.

	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=DEVDEV