OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: PCI cap for larger offsets/lengths


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.

'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.

Dave

--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]