lkml.org 
[lkml]   [2011]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT PULL] Native Linux KVM tool for 3.1

    * Avi Kivity <avi@redhat.com> wrote:

    > On 07/25/2011 12:41 PM, Ingo Molnar wrote:

    > > Look at tools/kvm/ - i cannot do anything useful without a Linux
    > > kernel under it. It's as deeply bound to the Linux kernel as it
    > > gets.
    >
    > The actual code that interacts with the kernel is pretty small, and
    > will grow smaller (as a fraction) in time.

    Look at the example i have given in my other mail, conceptual
    interaction goes beyond the strict KVM (and hardware) ABIs themselves
    - for every guest side driver there's a host side piece of
    functionality.

    What we found is that there's real benefits from tools/kvm/hw/i8042.c
    using the same conventions and constants as
    drivers/input/serio/i8042.c.

    The two pieces of code are obviously independent ABI-wise - but to
    developers working on both sides of the fence it's very useful to
    have the code look similar and familiar.

    Some other pieces of code share library functionality between the
    kernel and tools/kvm/.

    > > Then look at the actual drivers and interfaces within tools/kvm/.
    > > It's using the same symbols and conventions for 'guest' and
    > > 'host' side.
    > >
    > > Check out tools/kvm/hw/i8042.c and match it up with
    > > include/linux/serio.h and drivers/input/serio/i8042.c - you can
    > > literally walk from one side to the other and understand how
    > > guest and host are tightly related not just functionality but
    > > also implementation wise.
    > >
    > > This is how Qemu should be doing it as well btw., to ease the
    > > debugging of host/guest interaction bugs and to ease development.
    >
    > No. That ties the guest and host interfaces together. [...]

    Why would it tie the interfaces together? For a guest and host driver
    to be written in the same familiar conventions is useful for
    debugging and development easier but does not prevent both of those
    pieces to implement a precise interface. (Especially since in the
    i8042 case the host driver is used with real hardware as well.)

    > [...] If you change the guest to use a feature you didn't
    > implement previously in the host, it's suddenly broken when
    > virtualized.
    >
    > The right thing is to implement the hardware interface exactly per
    > spec, and ignore the guest(s) completely except for testing and
    > performance.

    You can certainly do that too - and nothing prevents from the guest
    and host driver to look and feel similar.

    But note that for many of these things there no such thing as a
    'hardware spec' that describes all the details and quirks - what we
    have are host PC drivers that have been implemented via many cycles
    of trial and error. That's especially true of i8042, the example i
    have given.

    Thanks,

    Ingo


    \
     
     \ /
      Last update: 2011-07-25 12:07    [W:0.030 / U:30.552 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site