Re: [GIT PULL] Native Linux KVM tool for 3.1

Ingo Molnar
2011-07-25T10:04:14Z

* 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