On Fri, Sep 21, 2018 at 10:54:59AM +0100, Dr. David Alan Gilbert wrote:
> Hi,
> We've got an experimental virtio device (using vhost-user) we're playing with
> that would like to share multiple large mappings from the client back to qemu.
CCing Michael Tsirkin and Gerd Hoffman. Gerd could use this for
virtio-gpu where some memory must be owned by the host.
>
> 'virtio_pci_cap' only has 32bit offset and length fields and so
> I've got a different capability to express larger regions:
>
>
> /* Additional shared memory capability */
> #define VIRTIO_PCI_CAP_SHARED_MEMORY_CFG 8
>
> struct virtio_pci_shm_cap {
> struct virtio_pci_cap cap;
> le32 offset_hi; /* Most sig 32 bits of offset */
> le32 length_hi; /* Most sig 32 bits of length */
> u8 id; /* To distinguish shm chunks */
> };
>
> One oddity is that I'm allowing multiple instances of this capability
> on one device, distinguished by their 'id' field which I've made device
> type specific, e.g.:
>
> #define VIRTIO_MYDEV_PCI_SHMCAP_ID_CACHE 0
> #define VIRTIO_MYDEV_PCI_SHMCAP_ID_JOURNAL 1
>
> Having more than one capability of the same type is a little different
> from what the virtio-spec currently suggests; it currently talks
> about 'order of preference suggested by the device' - i.e. two
> capabilities where the user picks one; in this case I'm using
> all of the instances for different things.
>
> If this makes sense to people, I'd be happy to write this up into a more
> formal change; if it doesn't I'd be interested to hear about alternative
> suggestions.
Another option is to define a unique PCI capability for each type:
struct virtio_pci_shm_cap {
struct virtio_pci_cap cap;
le32 offset_hi; /* Most significant 32 bits of offset */
le32 length_hi; /* Most significant 32 bits of length */
};
#define VIRTIO_PCI_CAP_MYDEV_SHM_CACHE 8
#define VIRTIO_PCI_CAP_MYDEV_SHM_JOURNAL 9
This way the "order of preference" semantics can be kept. The drawback
is consuming more PCI capability numbers.
Stefan