I have been closely following thisvery interresting discussion. Here's my summary: - PV capabilities is something we'll want - being able to surface virtual devices to the guest as PCI is preferable to Windows - we need an additional way to surface virtual devices to the guest. We don't have PCI on s390, and Ron doesn't want PCI in his guests. - complex interfaces are a mess to implement and maintain in different hypervisors and guest operating systems, we need a simple and clear structure like plan9 has today
To me, it looks like we need a virtual device abstraction both in the guest kernel and in the kvm/qemu. This abstraction needs to be simple and fast, and needs to be representable as PCI device and in a simpler way. PCI obstacles are supposed to be transparent to the virutal device. For me, plan9 does provide answers to a lot of above requirements. However, it does not provide capabilities for shared memory and it adds extra complexity. It's been designed to solve a different problem. I think the virtual device abstraction should provide the following functionality: - hypercall guest to host with parameters and return value - interrupt from host to guest with parameters - thin interrupt from host to guest, no parameters - shared memory between guest and host - dma access to guest memory, possibly via kmap on the host - copy from/to guest memory so long, Carsten ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
