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

    * Alexander Graf <> wrote:

    > On 18.03.2010, at 09:56, Ingo Molnar wrote:
    > >
    > > * Avi Kivity <> wrote:
    > >
    > >> On 03/17/2010 10:10 AM, Ingo Molnar wrote:
    > >>>
    > >>>> It's about who owns the user interface.
    > >>>>
    > >>>> If qemu owns the user interface, than we can satisfy this in a very
    > >>>> simple way by adding a perf monitor command. If we have to support third
    > >>>> party tools, then it significantly complicates things.
    > >>>
    > >>> Of course illogical modularization complicates things 'significantly'.
    > >>
    > >> Who should own the user interface then?
    > >
    > > If qemu was in tools/kvm/ then we wouldnt have such issues. A single patch (or
    > > series of patches) could modify tools/kvm/, arch/x86/kvm/, virt/ and
    > > tools/perf/.
    > It's not a 1:1 connection. There are more users of the KVM interface. To
    > name a few I'm aware of:
    > - Mac-on-Linux (PPC)
    > - Dolphin (PPC)
    > - Xenner (x86)
    > - Kuli (s390)

    There must be a misunderstanding here: tools/perf/ still has a clear userspace
    interface and ABI. There's external projects making use of it: sysprof and
    libpfm (and probably more i dont know about it). Those projects are also
    contributing back.

    Still it's _very_ useful to have a single reference implementation under
    tools/perf/ where we concentrate the best of the code. That is where we make
    sure that each new kernel feature is appropriately implemented in user-space
    as well, that the combination works well together and is releasable to users.
    That is what keeps us all honest: the latency of features is much lower, and
    there's no ping-pong of blame going on between the two components in case of
    bugs or in case of misfeatures.

    Same goes for KVM+Qemu: it would be so much nicer to have a single,
    well-focused reference implementation under tools/kvm/ and have improvements
    flow into that code base.

    That way KVM developers cannot just shrug "well, GUI suckage is a user-space
    problem" - like the answers i got in the KVM usability thread ...

    The buck will stop here.

    And if someone thinks he can do better an external project can be started
    anytime. (it may even replace the upstream thing if it's better)

    > Having a clear userspace interface is the only viable solution there. And if
    > you're interested, look at my MOL enabling patch. It's less than 500 lines
    > of code.

    Why do you suppose that what i propose is an "either or" scenario?

    It isnt. I just suggested that instead of letting core KVM fragment its limbs
    into an external entity, put your name behind one good all-around solution and
    focus the development model into a single project.

    I.e. do what KVM has done originally in the kernel space to begin with - and
    where it was so much better than Xen: single focus.

    Learn from what KVM has done so well in the initial years and use the concept
    on the user-space components as well. The very same arguments that caused KVM
    to integrate into the upstream kernel (instead of being a separate project)
    are a valid basis to integrate the user-space components into tools/kvm/. Dont
    forget your roots and dont assume all your design decisions were correct.

    > The kernel/userspace interface really isn't the difficult part. Getting
    > device emulation working properly, easily and fast is.

    The kernel/userspace ABI is not difficult at all. Getting device emulation
    working properly, easily and fast indeed is. And my experience is that it is
    not working properly nor quickly at the moment, at all. (see the 'KVM
    usability' thread)

    Getting device emulation working properly often involves putting certain
    pieces that are currently done in Qemu into kernel-space. That kind of
    'movement of emulation technology' from user-space component into the
    kernel-space component [or back] would very clearly be helped if those two
    components were in the same repository.

    And i have first-hand experience there: we had (and have) similar scenarios
    with tools/perf routinely. We did some aspects in user-space, then decided to
    do it in kernel-space. Sometimes we moved kernel bits to user-space. It was
    very easy and there were no package and version complications as it's a single
    project. Sometimes we even moved bits back and forth until we found the right



     \ /
      Last update: 2010-03-18 11:13    [W:0.027 / U:1.612 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site