Re: [RFC] Unify KVM kernel-space and user-space code into a single project

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/18/2010 11:28 AM, Ingo Molnar wrote:
>>> There are all kernel space projects, going through Xorg would be a
>>> horrible waste of performance for full-screen virtualization. It's fine
>>> for the windowed or networked case (and good as a compatibility fallback),
>>> but very much not fine for local desktop use.
>>>        
> For the full-screen case (which is a very common mode of using a guest OS on
> the desktop) there's not much of window management needed. You need to
> save/restore as you switch in/out.
>    

I don't think I've ever used full-screen mode with my VMs and I use 
virtualization on a daily basis.

We hear very infrequently from users using full screen mode.

>> 3D graphics virtualization is extremely difficult in the non-passthrough
>> case.  It really requires hardware support that isn't widely available today
>> (outside a few NVIDIA chipsets).
>>      
> Granted it's difficult in the general case.
>
>    
>>>> Xorg framebuffer driver doesn't implement any of the optimizations that the
>>>> Linux framebuffer supports and the Xorg driver does not provide use the
>>>> kernel's interfaces for providing update regions.
>>>>
>>>> Of course, we need to pull in X into the kernel to fix this, right?
>>>>          
>>> FYI, this part of X has already been pulled into the kernel, it's called
>>> DRM. If then it's being expanded.
>>>        
>> It doesn't provide the things we need to a good user experience. You need
>> things like an absolute input device, host driven display resize, RGBA
>> hardware cursors.  None of these go through DRI and it's those things that
>> really provide the graphics user experience.
>>      
> With KSM the display resize is in the kernel.

KMS

>   Cursor management is not. Yet: i
> think it would be a nice feature as the cursor could move even if Xorg is
> blocked or busy with other things.
>    

If it was all in the kernel, we'd try to support it.

>>>> Any sufficiently complicated piece of software is going to interact with
>>>> a lot of other projects.  The solution is not to pull it all into one
>>>> massive repository.  It's to build relationships and to find ways to
>>>> efficiently work with the various communities.
>>>>          
>>> That's my whole point with this thread: the kernel side of KVM and qemu,
>>> but all practical purposes should not be two 'separate communities'. They
>>> should be one and the same thing.
>>>        
>> I don't know why you keep saying this.  The people who are in these
>> "separate communities" keep claiming that they don't feel this way.
>>      
> If you are not two separate communities but one community, then why do you go
> through the (somewhat masochistic) self-punishing excercise of keeping the
> project in two different pieces?
>    

I don't see any actual KVM developer complaining about this so I'm not 
sure why you're describing it like this.

> In a distant past Qemu was a separate project and KVM was just a newcomer who
> used it for fancy stuff. Today as you say(?) the two communities are one and
> the same. Why not bring it to its logical conclusion?
>    

We lose a huge amount of users and contributors if we put QEMU in the 
Linux kernel.  As I said earlier, a huge number of our contributions 
come from people not using KVM.

>> I'm not just saying this to be argumentative.  Many of the people in the
>> community have thought this same thing, and tried it themselves, and we've
>> all come to the same conclusion.
>>
>> It's certainly possible that we just missed the obvious thing to do but
>> we'll never know that unless someone shows us.
>>      
> I'm not aware of anyone in the past having attempted to move qemu to
> tools/kvm/ in the uptream kernel repo, and having reported on the experiences
> with such a contribution setup. (obviously it's not possible at all without
> heavy cooperation and acceptance from you and Avi, so this will probably
> remain a thought experiment forever)
>    

We've tried to create a "clean" version of QEMU specifically for KVM.  
Moving it into tools/kvm would be the second step.  We've all failed on 
the firs step.

> If then you must refer to previous attempts to 'strip down' Qemu, right? Those
> attempts didnt really solve the fundamental problem of project code base
> separation.
>    

If the problem is combining the two, I've sent you a patch that you can 
put into tip.git if you're so inclined.

Regards,

Anthony Liguori

> 	Ingo
>