Re: KVM usability

[Avi Kivity <avi@redhat.com>]

On 03/02/2010 02:30 AM, Ingo Molnar wrote:
> * Anthony Liguori<anthony@codemonkey.ws>  wrote:
>
>    
>> On 03/01/2010 02:56 PM, Ingo Molnar wrote:
>>      
>>> Here's our experience with tools/perf/. Hosting the project in the kernel
>>> proper helped its quality immensely:
>>>
>>>   - It's much easier to synchronize new features on the kernel side and on the
>>>     user-space side. The two go hand in hand - they are often implemented in
>>>     the same patch.
>>>        
>> Kernel features and qemu features usually don't have a great amount of
>> intersect.  All of the problems you've described are strictly in the qemu
>> space.
>>      
> IMO that's a bug, not a feature. There should be a lot more interaction
> between kvm-qemu and KVM: for example Qemu should have a feature to install
> paravirt drivers in the guest, this would be helped by living in the kernel
> repo.
>    

The paravirt drivers are completely disassociated from kvm.  You can run 
a virtio driver with qemu but without kvm (or even with virtualbox, 
without either qemu or kvm).

For Linux, installing drivers automatically in older guests is 
impossible due to Documentation/stable_api_nonsense.txt and unnecessary 
in newer Linux (same reason).  For non-Linux, this feature certainly 
makes sense, but I don't see how putting qemu in tools/kvm helps it much.


>>>   - It's released together with the kernel, which gives a periodic 3 months
>>>     release frequency. Not too slow, not too fast.
>>>        
>> qemu release range in length from 3-6 months depending on
>> distribution schedules.  They are very regular.
>>      
> The Linux kernel is released every 3 months, +- one week. Our experience is
> that even 6 months would be (way) too painful for distros.
>    

It would also be horrible for internal synchronization.  That's not an 
issue with qemu, nor do I think that six months would hurt distros any.  
In any case, we respond to feedback (which we happen to generate in the 
first place).

>>>   - Code quality requirements are that of the kernel's. No muck allowed and
>>>     it's not hard to explain what kind of code is preferred.
>>>        
>> Code quality is subjective.  We have a different coding style.
>>      
> That's somewhat of a problem when for example a KVM kernel-space developer
> crosses into Qemu code and back. Two separate styles, etc. I certainly
> remember a 'culture clash' when going from the kernel into Qemu and back.
> Different principles, different culture. It's better to standardize.
>    

That sounds like a trivial thing.

>>>   - Tool breakage bisection is a breeze: there's never any mismatch between
>>>     tools/perf and the kernel counterpart. With a separate package we'd
>>>     have more complex test and bisection scenarios.
>>>        
>> KVM has a backwards compatible ABI so there's no such thing as mismatch
>> between user and kernel space.
>>      
> perf too is ABI compatible (between releases) - still bisection is a lot
> easier because the evolution of a particular feature can be bisected back to.
>
> Btw., KVM certainly ha ABI breakages around 2.6.16(?) when it was added, even
> of released versions. Also, within a development version you sure sometimes
> iterate a new ABI component, right? With a time-coherent repository both
> intentional and unintentional breakages and variations can be bisected back to
> as they happened.
>
> This is an unconditional advantage and i made use of it numerous times.
>    

Try old qemu on new kernel.  If it works, bisect qemu.  If it fails, 
bisect the kernel.

If you're lucky it is qemu that was broken, so no kernel rebuilds and 
reboots.  Since qemu is much larger than kvm, it is more likely to have 
introduced the problem, so the bisect goes faster.

>> You could argue that any project should be in the kernel for these
>> reasons.  I see no reason why something as like KVM should be part
>> of the kernel and udev shouldn't be.
>>      
> Yes, you are quite correct: udev has been argued to be a prime candidate for
> tools/. (and some other kernel utilities as well)
>
>  From a design POV all 'system/kernel utilities', which make little sense
> without the kernel and are license compatible can (and arguably should) move
> there.
>
> Obviously there's no pressure to do so - it's only an opportunity.
>    

Only a small part of qemu, especially the desktop oriented qemu that you 
seem to want, actually interfaces with kvm.  Mostly it involves 
emulating hardware, issuing I/O, talking to management layers, 
presenting a user interface, etc.  It's not a system/kernel utility.

>>> etc.
>>>
>>> In the KVM context this was obviously only a suggestion though. If i were
>>> hacking on kvm-qemu i wouldnt hesitate for a moment to do it: the project
>>> has very close ties to kernel-KVM and repo level unification would create
>>> various synergies - but you are hacking on it, not me ;-)
>>>
>>> If i were doing it i'd probably start with a cleaned up and stripped down
>>> version of Qemu, to make it eligible for mainline kernel inclusion.
>>>        
>> You should try it.  I think you'll find that it's not as obvious thing to do
>> as you think it is.
>>      
> A few years ago I looked into cleaning up Qemu, when i hacked KVM and Qemu. I
> also wanted to have a 'qemu light', which is both smaller and cleaner, and
> still fits to KVM. It didnt look particularly hard back then - but it's
> certainly not zero amount of work.
>
> Cleanups pay - they make a piece of code both more hackable, more debuggable
> and more appealing to new developers. (i suspect you have no argument with
> that notion) Also note that it wasnt me who suggested that Qemu wouldnt fit
> the kernel standards as-is - it was raised by others in this discussion.
>    

I'm sure patches to clean up qemu will be more than welcome on qemu-devel.

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