Re: [PATCH vhost v6 08/11] virtio_ring: introduce virtqueue_dma_dev()

[Gerd Hoffmann <kraxel@redhat.com>]

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@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

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization