Re: [PATCH/RFC 7/9] Virtual network guest device driver

[Carsten Otte <cotte-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>]

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/