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

Ingo Molnar
2010-03-18T16:28:54Z

* 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