Christian Bornträger wrote:
Am Dienstag 19 Mai 2009 20:39:24 schrieb Anthony Liguori:
Perhaps something that maps closer to the current add_buf/get_buf API.
Something like:
struct iovec *(*map_buf)(struct virtqueue *vq, unsigned int *out_num,
unsigned int *in_num);
void (*unmap_buf)(struct virtqueue *vq, struct iovec *iov, unsigned int
out_num, unsigned int in_num);
There's symmetry here which is good. The one bad thing about it is
forces certain memory to be read-only and other memory to be
read-write. I don't see that as a bad thing though.
I think we'll need an interface like this so support driver domains too
since "backend". To put it another way, in QEMU, map_buf ==
virtqueue_pop and unmap_buf == virtqueue_push.
You are proposing that the guest should define some guest memory to be used as
shared memory (some kind of replacement), right?
No. map_buf() returns a mapped region of memory. Where that memory
comes from is up to the transport. It can be the result of an ioremap
of a PCI BAR.
The model of virtio frontends today is:
o add buffer of guest's memory
o let backend do something with it
o get back buffer of guest's memory
The backend model (as implemented by QEMU) is:
o get buffer of mapped front-end memory
o do something with memory
o give buffer back
For implementing persistent shared memory, you need a vring with enough
elements to hold all of the shared memory regions at one time. This
becomes more practical with indirect scatter/gather entries.
Of course, whether vring is used at all is a transport detail.
Regards,
Anthony Liguori
--
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
