lkml.org 
[lkml]   [2010]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] Unify KVM kernel-space and user-space code into a single project

    * 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


    \
     
     \ /
      Last update: 2010-03-18 19:11    [W:4.227 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site