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

[Ingo Molnar <mingo@elte.hu>]

* Anthony Liguori <anthony@codemonkey.ws> wrote:

> On 03/18/2010 10:17 AM, Ingo Molnar wrote:
> >* Anthony Liguori<anthony@codemonkey.ws>  wrote:
> >
> >>On 03/18/2010 08:00 AM, Ingo Molnar wrote:
> >>>>[...]  kvm in fact knows nothing about vga, to take your last example.
> >>>>[...]
> >>>Look at the VGA dirty bitmap optimization a'ka the KVM_GET_DIRTY_LOG
> >>>ioctl.
> >>>
> >>>See qemu/kvm-all.c's kvm_physical_sync_dirty_bitmap().
> >>>
> >>>It started out as a VGA optimization (also used by live migration) and
> >>>even today it's mostly used by the VGA drivers - albeit a weak one.
> >>>
> >>>I wish there were stronger VGA optimizations implemented, copying the
> >>>dirty bitmap is not a particularly performant solution. (although it's
> >>>certainly better than full emulation) Graphics performance is one of the
> >>>more painful aspects of KVM usability today.
> >>We have to maintain a dirty bitmap because we don't have a paravirtual
> >>graphics driver.  IOW, someone needs to write an Xorg driver.
> >>
> >>Ideally, we could just implement a Linux framebuffer device, right?
> >No, you'd want to interact with DRM.
> 
> Using DRM doesn't help very much.  You still need an X driver and most of 
> the operations you care about (video rendering, window movement, etc) are 
> not operations that need to go through DRM.

You stripped out this bit from my reply:

> > 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.

> 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. 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.

> >> 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?

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?

> 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)

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.

	Ingo