Re: KVM usability

[Zachary Amsden <zamsden@redhat.com>]

On 02/27/2010 07:25 AM, Ingo Molnar wrote:
> * Zachary Amsden<zamsden@redhat.com>  wrote:
>
> [...]
>    
>> Second, it's not over-modularized.  The modules are the individual
>> components of the architecture.  How would you propose to put it
>> differently.  They really can't naturally combine.  And with the
>> code quality of qemu in general being problematic by Linux kernel
>> standards, it's not natural to move the device emulation directly
>> into the kernel module.  So this is why we are where we are today.
>>      
> I'm not talking about moving it into a kernel _module_ - albeit that
> alone is a worthwile thing to do for any performance sensitive hw
> component.
>
> I was talking about the option of a clean, stripped down Qemu base
> hosted in the kernel proper, in linux/tools/kvm/ or so. If i were
> running a virtualization effort it would be the first place i'd
> consider to put my tooling into.
>    

The problem is there is no way to clean and strip down the Qemu code.  
It's got nicely abstracted bus and device interfaces, for example, but 
then these go poking under the covers at things which require 
interacting with the display rendering library or remoting interface, 
which is not something to reasonably do in the kernel.

So ripping out a clean part interface like PCI bus infrastructure and 
using it in the kernel, for example, does nothing except put that 
infrastructure in two different places, because everything the kernel 
does, userspace will have to do again anyway.  So now you have twice as 
much code involving the same idea and you have to keep the pieces in 
sync and from trampling each other.

The only parts that warrant such complexity and high risk for bugs are 
performance critical things like the PIT and APIC.

Zach