On Thursday 16 July 2009, Gregory Haskins wrote: > Background: The original vbus code was tightly integrated with kvm.ko. Avi > suggested that we abstract the interfaces such that it could live outside > of kvm. The code is still highly kvm-specific, you would not be able to use it with another hypervisor like lguest or vmware player, right? > Example usage: QEMU instantiates a guest, and an external module "foo" > that desires the ability to interface with the guest (say via > open("/dev/foo")). QEMU may then issue a KVM_GET_VMID operation to acquire > the u64-based vmid, and pass it to ioctl(foofd, FOO_SET_VMID, &vmid). > Upon receipt, the foo module can issue kvm_xinterface_find(vmid) to acquire > the proper context. Internally, the struct kvm* and associated > struct module* will remain pinned at least until the foo module calls > kvm_xinterface_put(). Your approach allows passing the vmid from a process that does not own the kvm context. This looks like an intentional feature, but I can't see what this gains us. > As a final measure, we link the xinterface code statically > into the kernel so that callers are guaranteed a stable interface to > kvm_xinterface_find() without implicitly pinning kvm.ko or racing against > it. I also don't understand this. Are you worried about driver modules breaking when an externally-compiled kvm.ko is loaded? The same could be achieved by defining your data structures kvm_xinterface_ops and kvm_xinterface in a kernel header that is not shipped by kvm-kmod but always taken from the kernel headers. It does not matter if the entry points are build into the kernel or exported from a kvm.ko as long as you define a fixed ABI. What is the problem with pinning kvm.ko from another module using its features? Can't you simply provide a function call to lookup the kvm context pointer from the file descriptor to achieve the same functionality? To take that thought further, maybe the dependency can be turned around: If every user (pci-uio, virtio-net, ...) exposes a file descriptor based interface to user space, you can have a kvm ioctl to register the object behind that file descriptor with an existing kvm context to associate it with a guest. That would nicely solve the life time questions by pinning the external object for the life time of the kvm context rather than the other way round, and it would be completely separate from kvm in that each such object could be used by other subsystems independent of kvm. Arnd <>< -- 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