Message-ID: <4BA256FE.5080501@codemonkey.ws>
Date:	Thu, 18 Mar 2010 11:38:22 -0500
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Avi Kivity <avi@...hat.com>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Sheng Yang <sheng@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	oerg Roedel <joro@...tes.org>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>, ziteng.huang@...el.com,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Fr?d?ric Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single
 project

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
>    

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists