Re: PCI cap for larger offsets/lengths

[Stefan Hajnoczi <stefanha@redhat.com>]

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

Attachment: signature.asc
Description: PGP signature