Re: KVM usability

[Avi Kivity <avi@redhat.com>]

On 02/27/2010 07:25 PM, 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.
>    

Moving qemu into the kernel is preposterous.  It's a huge code base 
(even a stripped down version) with many external dependencies.  You're 
converting a guest crash into a host crash, and a simple binary update 
into a reboot.

What makes sense is identifying the performance critical bits and 
creating generally useful kernel interfaces that can be used to speed 
them up, or kvm-specific kernel accelerations.  Example include 
preadv/pwritev (generic) and vhost-net (specific).

> 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.
>
> It would be a no-brainer: most of the devs come from the KVM side, and
> KVM itself makes little sense without Qemu, and Qemu makes little sense
> without KVM these days. (and i know about the non-KVM and non-x86
> roots of Qemu - still, it's not a significant piece of usage today)
>    

It's true that qemu development is dominated these days by kvm 
development.  If the qemu community was dysfunctional (as it once was) 
then it makes sense to fork it.  But it isn't, so it doesn't.

Note also that kvm is not x86 only.

>> Third, it's the maintainers upstream who are in charge of KVM
>> quality as a whole - when you are talking about upstream code
>> quality, and the package maintainers who are in charge of KVM
>> quality as a whole - when you are talking about a distro.  This is
>> nothing new - it's just a statement of decentralization.
>>      
> It's certainly nothing new. Nor was the suckage of CVS newup until
> Git came along and changed the game on a fundamental basis.
>    

Bitkeeper deserves some credit here.

> Suckage is there to be fought all the time.
>    

Send patches, not flames.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.