Linux Virtualization - Apr 2023 - [PATCH vhost v6 08/11] virtio_ring: introduce virtqueue_dma_dev()

On Tue, Apr 11, 2023 at 12:10?PM Christoph Hellwig <hch at infradead.org>
wrote:
>
> On Tue, Apr 11, 2023 at 11:56:47AM +0800, Jason Wang wrote:
> > > The DMA device for virtio_pci is the underlying PCI device,
always.
> > > !VIRTIO_F_ACCESS_PLATFORM means there is no dma device at all. 
Because
> > > of all these things you can't just expose a pointer to the
dma_device
> > > as that is just a completely wrong way of thinking about the
problem.
> >
> > Ok, so if there's no DMA at all we should avoid using the DMA API
> > completely. This means we should check dma_dev against NULL in
> > virtio_has_dma_quirk().
>
> No nee to add a check to virtio_has_dma_quirk.
Ok, just to clarify, I meant there could be a case where the virtqueue
is emulated by software, in this case we need check whether the
virtqueue has a dma device or not in vring_use_dma_api(). If not we
need return false.
>
> But looking at virtio_has_dma_quirk shows that virtio-gpu is
> pretty messed up already as well.
>
> It can't really poke into the DMA details.  We'll need core virtio
> helpers for allocating and syncing a sg_table instead and make
> virtio_has_dma_quirk private to the core.
Adding Gerd.

Thanks
>

On Tue, Apr 11, 2023 at 12:54:46PM +0800, Jason Wang
wrote:
> Ok, just to clarify, I meant there could be a case where the virtqueue
> is emulated by software, in this case we need check whether the
> virtqueue has a dma device or not in vring_use_dma_api(). If not we
> need return false.
Well, that's what vring_use_dma_api basically does.  Such devics
just should never have VIRTIO_F_ACCESS_PLATFORM set.  If there is
a really good reason for such a device to have VIRTIO_F_ACCESS_PLATFORM
set we'd need an extra quirk in vring_use_dma_api indeed.

On Tue, Apr 11, 2023 at 12:54:46PM +0800, Jason Wang
wrote:
> On Tue, Apr 11, 2023 at 12:10?PM Christoph Hellwig <hch at
infradead.org> wrote:
> >
> > On Tue, Apr 11, 2023 at 11:56:47AM +0800, Jason Wang wrote:
> > > > The DMA device for virtio_pci is the underlying PCI device,
always.
> > > > !VIRTIO_F_ACCESS_PLATFORM means there is no dma device at
all.  Because
> > > > of all these things you can't just expose a pointer to
the dma_device
> > > > as that is just a completely wrong way of thinking about the
problem.
> > >
> > > Ok, so if there's no DMA at all we should avoid using the DMA
API
> > > completely. This means we should check dma_dev against NULL in
> > > virtio_has_dma_quirk().
> >
> > No nee to add a check to virtio_has_dma_quirk.
> 
> Ok, just to clarify, I meant there could be a case where the virtqueue
> is emulated by software, in this case we need check whether the
> virtqueue has a dma device or not in vring_use_dma_api(). If not we
> need return false.
> 
> > But looking at virtio_has_dma_quirk shows that virtio-gpu is
> > pretty messed up already as well.
Yes.  For gem objects allocated in guest ram virtio-gpu effectively
passes a scatter list to the host.  It doesn't use vrings for that
though, so it has to re-implement some of the logic the virtio core
already has for the vrings.
> > It can't really poke into the DMA details.  We'll need core
virtio
> > helpers for allocating and syncing a sg_table instead and make
> > virtio_has_dma_quirk private to the core.
That should work.

take care,
  Gerd