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

[Avi Kivity <avi@redhat.com>]

On 07/25/2011 01:03 PM, Ingo Molnar wrote:
> >  >  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.)

The driver is under no requirement to use all of the functionality of 
the device.  On the other hand, the device emulation has to be complete, 
or it risks not working with some past or future version of the driver, 
or with another OS (if you support that).

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

The device need not implement any quirks - it can implement the spec 
exactly.  As long as the driver can drive a standard device, all is fine.

Specs for the 8042 certainly exist.

-- 
error compiling committee.c: too many arguments to function