On Mon, Nov 26, 2018 at 03:51:45PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > So, I'm wondering whenever it makes sense to just do the same for your
> > > device. Just use one pci bar as shared memory umbrella, specify that
> > > one using the virtio vendor cap, then have sub-regions within that bar
> > > for the various regions you have. Manage them dynamically (using
> > > device-specific virtio commands) or just have a static configuration (in
> > > device-specific config space).
> >
> > Ours are static subdivisions; so it felt easier to declare them; it's a
> > shame to make that device specific.
>
> Shared memory handling is device specific anyway, so I fail to see why
> this is a problem. Or do you want place virtio queues there (which
> could be common ground for multiple device types) ?
>
> > > That avoids the problem with multiple capabilities of the same kind, and
> > > it also avoids exhausting the cap IDs quicky if every device defines
> > > their own VIRTIO_FOO_DEVICE_PCI_SHMCAP_ID_BAR_REGION.
> >
> > Is having multiple capabilities of the same type actually a problem, or
> > is it just historical in the defitinition of virtio?
>
> I think the reason is that you can in theory have the same region twice,
> once in an IO bar and once in an MMIO bar, and then the guest could
> prefer the IO bar if possible and use the MMIO bar otherwise (PCIe slot
> without IO address window for example). I think that was never actually
> done in practice, and for (prefetchable) memory bars it doesn't make
> sense at all. So that would unlikely be a problem in practice.
>
> Running out of capability IDs could become a real problem though.
If we use a dedicated prefetchable MMIO BAR for shared memory resources,
then that BAR is unavailable. For example, if the virtio-pci transport
itself ever wants to use a prefetchable MMIO BAR too.
I would keep the indirection offered by PCI capabilities so that devices
retain the ability to decide how exactly BARs are used without requiring
spec or driver changes.
Stefan