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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
