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

[Anthony Liguori]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/