search for: virtio_has_dma_quirk

...ct.c +++ b/drivers/gpu/drm/virtio/virtgpu_object.c @@ -141,7 +141,7 @@ static int virtio_gpu_object_shmem_init(struct virtio_gpu_device *vgdev, struct virtio_gpu_mem_entry **ents, unsigned int *nents) { - bool use_dma_api = !virtio_has_iommu_quirk(vgdev->vdev); + bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev); struct virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo); struct scatterlist *sg; int si, ret; diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index 9e663a5d9952..53af60d484a4 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b...

Use generic names for the quirks to make it clear it is not just about the IOMMU, it's about DMA access in general. changes from v1: added patch 2 Michael S. Tsirkin (2): virtio: VIRTIO_F_IOMMU_PLATFORM -> VIRTIO_F_ACCESS_PLATFORM virtio: virtio_has_iommu_quirk -> virtio_has_dma_quirk arch/um/drivers/virtio_uml.c | 2 +- drivers/gpu/drm/virtio/virtgpu_object.c | 2 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++-- drivers/vdpa/ifcvf/ifcvf_base.h | 2 +- drivers/vdpa/vdpa_sim/vdpa_sim.c | 4 ++-- drivers/vhost/net.c | 4 ++-...

These days dma ops can be overridden per device, and the virtio core uses that to handle the dma quirks transparently for the rest of the kernel. So we can drop the virtio_has_dma_quirk() checks, just use the dma api unconditionally and depend on the virtio core having setup dma_ops as needed. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_object.c | 19 ++++++------------- drivers/gpu/drm/virtio/virtgpu_vq.c | 16 ++++++---------...

These days dma ops can be overridden per device, and the virtio core uses that to handle the dma quirks transparently for the rest of the kernel. So we can drop the virtio_has_dma_quirk() checks, just use the dma api unconditionally and depend on the virtio core having setup dma_ops as needed. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_object.c | 19 ++++++------------- drivers/gpu/drm/virtio/virtgpu_vq.c | 16 ++++++---------...

...e cares about anymore? > > > > I think these days it is possible to override dma_ops per device, which > > in turn allows virtio to deal with the quirks without the rest of the > > kernel knowing about these details. > > > > I also think virtio-gpu can drop the virtio_has_dma_quirk() checks, just > > use the dma api path unconditionally and depend on virtio core having > > setup dma_ops in a way that it JustWorks[tm]. I'll look into that next. > > The comment above vring_use_dma_api() suggests that this has not yet > happened, that's why I'm...

...verridden" or "are"? The comment above vring_use_dma_api() suggests that's not yet done. If that's wrong then I think updating the comment would be really good. -Daniel > uses that to handle the dma quirks transparently for the rest of the > kernel. So we can drop the virtio_has_dma_quirk() checks, just use > the dma api unconditionally and depend on the virtio core having setup > dma_ops as needed. > > Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> > --- > drivers/gpu/drm/virtio/virtgpu_object.c | 19 ++++++------------- > drivers/gpu/drm/virtio/vi...

...h not ... Or is that all very > old stuff only that no one cares about anymore? I think these days it is possible to override dma_ops per device, which in turn allows virtio to deal with the quirks without the rest of the kernel knowing about these details. I also think virtio-gpu can drop the virtio_has_dma_quirk() checks, just use the dma api path unconditionally and depend on virtio core having setup dma_ops in a way that it JustWorks[tm]. I'll look into that next. take care, Gerd

On Fri, Jul 27, 2018 at 10:58:05AM +0100, Will Deacon wrote: > > I just wanted to say that this patch series provides a means for us to > force the coherent DMA ops for legacy virtio devices on arm64, which in turn > means that we can enable the SMMU with legacy devices in our fastmodel > emulation platform (which is slowly being upgraded to virtio 1.0) without > hanging during

On Fri, Jul 27, 2018 at 10:58:05AM +0100, Will Deacon wrote: > > I just wanted to say that this patch series provides a means for us to > force the coherent DMA ops for legacy virtio devices on arm64, which in turn > means that we can enable the SMMU with legacy devices in our fastmodel > emulation platform (which is slowly being upgraded to virtio 1.0) without > hanging during

...TIO_F_IO_BARRIER to > VIRTIO_F_REAL_DEVICE. It got stuck since "real" sounds vague to people, > e.g. what if it's a VF - is that real or not? But I can see something > like e.g. VIRTIO_F_PLATFORM_DMA gaining support. > > We would then rename virtio_has_iommu_quirk to virtio_has_dma_quirk > and test VIRTIO_F_PLATFORM_DMA in addition to the IOMMU thing. I don't really care about the exact naming, and indeed a device that sets the flag doesn't have to be a 'real' device - it just has to act like one. I explained all the issues that this means (at least relating to...

...TIO_F_IO_BARRIER to > VIRTIO_F_REAL_DEVICE. It got stuck since "real" sounds vague to people, > e.g. what if it's a VF - is that real or not? But I can see something > like e.g. VIRTIO_F_PLATFORM_DMA gaining support. > > We would then rename virtio_has_iommu_quirk to virtio_has_dma_quirk > and test VIRTIO_F_PLATFORM_DMA in addition to the IOMMU thing. I don't really care about the exact naming, and indeed a device that sets the flag doesn't have to be a 'real' device - it just has to act like one. I explained all the issues that this means (at least relating to...

...q, unsigned int total_sg) { /* @@ -269,7 +269,7 @@ static bool virtqueue_use_indirect(struct vring_virtqueue *vq, * unconditionally on data path. */ -static bool vring_use_dma_api(struct virtio_device *vdev) +static bool vring_use_dma_api(const struct virtio_device *vdev) { if (!virtio_has_dma_quirk(vdev)) return true; @@ -289,7 +289,7 @@ static bool vring_use_dma_api(struct virtio_device *vdev) return false; } -size_t virtio_max_dma_size(struct virtio_device *vdev) +size_t virtio_max_dma_size(const struct virtio_device *vdev) { size_t max_segment_size = SIZE_MAX; @@ -423,7 +423,7...

...> old stuff only that no one cares about anymore? > > I think these days it is possible to override dma_ops per device, which > in turn allows virtio to deal with the quirks without the rest of the > kernel knowing about these details. > > I also think virtio-gpu can drop the virtio_has_dma_quirk() checks, just > use the dma api path unconditionally and depend on virtio core having > setup dma_ops in a way that it JustWorks[tm]. I'll look into that next. The comment above vring_use_dma_api() suggests that this has not yet happened, that's why I'm asking. If this has happ...

...nt proposal to rename VIRTIO_F_IO_BARRIER to VIRTIO_F_REAL_DEVICE. It got stuck since "real" sounds vague to people, e.g. what if it's a VF - is that real or not? But I can see something like e.g. VIRTIO_F_PLATFORM_DMA gaining support. We would then rename virtio_has_iommu_quirk to virtio_has_dma_quirk and test VIRTIO_F_PLATFORM_DMA in addition to the IOMMU thing. -- MST

...> VIRTIO_F_REAL_DEVICE. It got stuck since "real" sounds vague to people, > > e.g. what if it's a VF - is that real or not? But I can see something > > like e.g. VIRTIO_F_PLATFORM_DMA gaining support. > > > > We would then rename virtio_has_iommu_quirk to virtio_has_dma_quirk > > and test VIRTIO_F_PLATFORM_DMA in addition to the IOMMU thing. > > I don't really care about the exact naming, and indeed a device that > sets the flag doesn't have to be a 'real' device - it just has to act > like one. I explained all the issues that this me...

...; > > > Yes, according to Jason's opinion, then XSK not need to do any modifications. > > > > Thanks. Yes AF_XDP does not need the per VQ device hack. We should probably rethink it. But as far as implementation goes, poking at VIRTIO_F_ACCESS_PLATFORM is wrong. Please use virtio_has_dma_quirk. > > > > > > > > > > > And if the dma_dev of rx and tx is different, then we can only disable > > > > XDP_SOCKET. > > > > > > We can start with this. > > > > > > Thanks > > > > > > > > > &...

...q, unsigned int total_sg) { /* @@ -269,7 +269,7 @@ static bool virtqueue_use_indirect(struct vring_virtqueue *vq, * unconditionally on data path. */ -static bool vring_use_dma_api(struct virtio_device *vdev) +static bool vring_use_dma_api(const struct virtio_device *vdev) { if (!virtio_has_dma_quirk(vdev)) return true; @@ -289,7 +289,7 @@ static bool vring_use_dma_api(struct virtio_device *vdev) return false; } -size_t virtio_max_dma_size(struct virtio_device *vdev) +size_t virtio_max_dma_size(const struct virtio_device *vdev) { size_t max_segment_size = SIZE_MAX; @@ -423,7 +423,7...

This patch series performs a clean up of the code in virtio_ring and virtio_pci, modifying it to conform with the Linux kernel coding style guidance [1]. The modifications ensure the code easy to read and understand. This small series does few short cleanups in the code. Patch-1 Remove unnecessary num zero check, which performs in power_of_2. Patch-2 Avoid using inline for small functions.

...R Michael Guralnik (2): net/mlx5: Enable QP number request when creating IPoIB underlay QP net/mlx5: Enable count action for rules with allow action Michael S. Tsirkin (44): virtio: VIRTIO_F_IOMMU_PLATFORM -> VIRTIO_F_ACCESS_PLATFORM virtio: virtio_has_iommu_quirk -> virtio_has_dma_quirk virtio_balloon: fix sparse warning virtio_ring: sparse warning fixup virtio: allow __virtioXX, __leXX in config space virtio_9p: correct tags for config space fields virtio_balloon: correct tags for config space fields virtio_blk: correct tags for config space fi...

This patch series performs a clean up of the code in virtio_ring and virtio_pci, modifying it to conform with the Linux kernel coding style guidance [1]. The modifications ensure the code easy to read and understand. This small series does few short cleanups in the code. Patch-1 Allow non power of 2 sizes for packed virtqueues. Patch-2 Avoid using inline for small functions. Patch-3 Use const to