> > 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.