* Avi Kivity <avi@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
