Re: [PATCH v2] Driver for Inter-VM shared memory device for KVM supporting interrupts.

[Anthony Liguori <anthony@codemonkey.ws>]

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