search for: vring_use_dma_api

...s/virtio/virtio_ring.c > index c8be1c4f5b55..37c143971211 100644 > --- a/drivers/virtio/virtio_ring.c > +++ b/drivers/virtio/virtio_ring.c > @@ -262,7 +262,7 @@ size_t virtio_max_dma_size(struct virtio_device *vdev) > { > size_t max_segment_size = SIZE_MAX; > > - if (vring_use_dma_api(vdev)) > + if (vring_use_dma_api(vdev) && vdev->dev.dma_mask) Hmm, might it make sense to roll that check up into vring_use_dma_api() itself? After all, if the device has no mask then it's likely that other DMA API ops wouldn't really work as expected either. Robin. >...

...s/virtio/virtio_ring.c > index c8be1c4f5b55..37c143971211 100644 > --- a/drivers/virtio/virtio_ring.c > +++ b/drivers/virtio/virtio_ring.c > @@ -262,7 +262,7 @@ size_t virtio_max_dma_size(struct virtio_device *vdev) > { > size_t max_segment_size = SIZE_MAX; > > - if (vring_use_dma_api(vdev)) > + if (vring_use_dma_api(vdev) && vdev->dev.dma_mask) Hmm, might it make sense to roll that check up into vring_use_dma_api() itself? After all, if the device has no mask then it's likely that other DMA API ops wouldn't really work as expected either. Robin. >...

On Thu, 2016-01-28 at 18:31 -0800, Andy Lutomirski wrote: > This is a kludge, but no one has come up with a a better idea yet. > We'll introduce DMA API support guarded by vring_use_dma_api(). > Eventually we may be able to return true on more and more systems, > and hopefully we can get rid of vring_use_dma_api() entirely some > day. > > Signed-off-by: Andy Lutomirski <luto at kernel.org> > --- > ?drivers/virtio/virtio_ring.c | 24 ++++++++++++++++++++++++...

On Thu, 2016-01-28 at 18:31 -0800, Andy Lutomirski wrote: > This is a kludge, but no one has come up with a a better idea yet. > We'll introduce DMA API support guarded by vring_use_dma_api(). > Eventually we may be able to return true on more and more systems, > and hopefully we can get rid of vring_use_dma_api() entirely some > day. > > Signed-off-by: Andy Lutomirski <luto at kernel.org> > --- > ?drivers/virtio/virtio_ring.c | 24 ++++++++++++++++++++++++...

...edhat.com> wrote: > On Mon, Feb 01, 2016 at 11:22:03AM +0000, David Woodhouse wrote: >> On Thu, 2016-01-28 at 18:31 -0800, Andy Lutomirski wrote: >> > This is a kludge, but no one has come up with a a better idea yet. >> > We'll introduce DMA API support guarded by vring_use_dma_api(). >> > Eventually we may be able to return true on more and more systems, >> > and hopefully we can get rid of vring_use_dma_api() entirely some >> > day. >> > >> > Signed-off-by: Andy Lutomirski <luto at kernel.org> >> > --- >> &gt...

...edhat.com> wrote: > On Mon, Feb 01, 2016 at 11:22:03AM +0000, David Woodhouse wrote: >> On Thu, 2016-01-28 at 18:31 -0800, Andy Lutomirski wrote: >> > This is a kludge, but no one has come up with a a better idea yet. >> > We'll introduce DMA API support guarded by vring_use_dma_api(). >> > Eventually we may be able to return true on more and more systems, >> > and hopefully we can get rid of vring_use_dma_api() entirely some >> > day. >> > >> > Signed-off-by: Andy Lutomirski <luto at kernel.org> >> > --- >> &gt...

...5b55..37c143971211 100644 >>> --- a/drivers/virtio/virtio_ring.c >>> +++ b/drivers/virtio/virtio_ring.c >>> @@ -262,7 +262,7 @@ size_t virtio_max_dma_size(struct virtio_device *vdev) >>> { >>> size_t max_segment_size = SIZE_MAX; >>> - if (vring_use_dma_api(vdev)) >>> + if (vring_use_dma_api(vdev) && vdev->dev.dma_mask) >> >> Hmm, might it make sense to roll that check up into vring_use_dma_api() >> itself? After all, if the device has no mask then it's likely that other >> DMA API ops wouldn't rea...

...5b55..37c143971211 100644 >>> --- a/drivers/virtio/virtio_ring.c >>> +++ b/drivers/virtio/virtio_ring.c >>> @@ -262,7 +262,7 @@ size_t virtio_max_dma_size(struct virtio_device *vdev) >>> { >>> size_t max_segment_size = SIZE_MAX; >>> - if (vring_use_dma_api(vdev)) >>> + if (vring_use_dma_api(vdev) && vdev->dev.dma_mask) >> >> Hmm, might it make sense to roll that check up into vring_use_dma_api() >> itself? After all, if the device has no mask then it's likely that other >> DMA API ops wouldn't rea...

This is a kludge, but no one has come up with a a better idea yet. We'll introduce DMA API support guarded by vring_use_dma_api(). Eventually we may be able to return true on more and more systems, and hopefully we can get rid of vring_use_dma_api() entirely some day. Signed-off-by: Andy Lutomirski <luto at kernel.org> --- drivers/virtio/virtio_ring.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)...

On Mon, Feb 01, 2016 at 11:22:03AM +0000, David Woodhouse wrote: > On Thu, 2016-01-28 at 18:31 -0800, Andy Lutomirski wrote: > > This is a kludge, but no one has come up with a a better idea yet. > > We'll introduce DMA API support guarded by vring_use_dma_api(). > > Eventually we may be able to return true on more and more systems, > > and hopefully we can get rid of vring_use_dma_api() entirely some > > day. > > > > Signed-off-by: Andy Lutomirski <luto at kernel.org> > > --- > > ?drivers/virtio/virtio_ri...

...de/linux/virtio.h | 2 +- 2 files changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index c5310eaf8b46..55cfecf030a1 100644 --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -289,12 +289,16 @@ static bool vring_use_dma_api(const struct virtio_device *vdev) return false; } -size_t virtio_max_dma_size(const struct virtio_device *vdev) +u32 virtio_max_dma_size(const struct virtio_device *vdev) { - size_t max_segment_size = SIZE_MAX; + u32 max_segment_size = U32_MAX; - if (vring_use_dma_api(vdev)) - max_segment_...

...t; > > > > > > So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be used on Xen/x86 > > > > always and on Xen/ARM if Linux is Dom0 (because it has foreign > > > > mappings.) That is why we have the if (xen_domain) return true; in > > > > vring_use_dma_api. > > > > > > VIRTIO_F_IOMMU_PLATFORM makes guest always use DMA ops. > > > > > > Xen hack predates VIRTIO_F_IOMMU_PLATFORM so it *also* > > > forces DMA ops even if VIRTIO_F_IOMMU_PLATFORM is clear. > > > > > > Unfortunately as a resu...

...t; > > > > > > So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be used on Xen/x86 > > > > always and on Xen/ARM if Linux is Dom0 (because it has foreign > > > > mappings.) That is why we have the if (xen_domain) return true; in > > > > vring_use_dma_api. > > > > > > VIRTIO_F_IOMMU_PLATFORM makes guest always use DMA ops. > > > > > > Xen hack predates VIRTIO_F_IOMMU_PLATFORM so it *also* > > > forces DMA ops even if VIRTIO_F_IOMMU_PLATFORM is clear. > > > > > > Unfortunately as a resu...

...ux's idea of a physical address into a real physical address (this is unneeded on ARM.) So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be used on Xen/x86 always and on Xen/ARM if Linux is Dom0 (because it has foreign mappings.) That is why we have the if (xen_domain) return true; in vring_use_dma_api. You might have noticed that I missed one possible case above: Xen/ARM DomU :-) Xen/ARM domUs don't need swiotlb_xen, it is not even initialized. So if (xen_domain) return true; would give the wrong answer in that case. Linux would end up calling the "normal" dma_ops, not swiotlb-xe...

...ux's idea of a physical address into a real physical address (this is unneeded on ARM.) So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be used on Xen/x86 always and on Xen/ARM if Linux is Dom0 (because it has foreign mappings.) That is why we have the if (xen_domain) return true; in vring_use_dma_api. You might have noticed that I missed one possible case above: Xen/ARM DomU :-) Xen/ARM domUs don't need swiotlb_xen, it is not even initialized. So if (xen_domain) return true; would give the wrong answer in that case. Linux would end up calling the "normal" dma_ops, not swiotlb-xe...

...t; 2 files changed, 9 insertions(+), 5 deletions(-) > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > index c5310eaf8b46..55cfecf030a1 100644 > --- a/drivers/virtio/virtio_ring.c > +++ b/drivers/virtio/virtio_ring.c > @@ -289,12 +289,16 @@ static bool vring_use_dma_api(const struct virtio_device *vdev) > return false; > } > > -size_t virtio_max_dma_size(const struct virtio_device *vdev) > +u32 virtio_max_dma_size(const struct virtio_device *vdev) LGTM But, should we change the parameter to vq, then use the dma_dev? @Jason Thanks. > {...

...ress (this is unneeded on ARM.) > > > > > > So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be used on Xen/x86 > > always and on Xen/ARM if Linux is Dom0 (because it has foreign > > mappings.) That is why we have the if (xen_domain) return true; in > > vring_use_dma_api. > > VIRTIO_F_IOMMU_PLATFORM makes guest always use DMA ops. > > Xen hack predates VIRTIO_F_IOMMU_PLATFORM so it *also* > forces DMA ops even if VIRTIO_F_IOMMU_PLATFORM is clear. > > Unfortunately as a result Xen never got around to > properly setting VIRTIO_F_IOMMU_PLATFO...

...ress (this is unneeded on ARM.) > > > > > > So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be used on Xen/x86 > > always and on Xen/ARM if Linux is Dom0 (because it has foreign > > mappings.) That is why we have the if (xen_domain) return true; in > > vring_use_dma_api. > > VIRTIO_F_IOMMU_PLATFORM makes guest always use DMA ops. > > Xen hack predates VIRTIO_F_IOMMU_PLATFORM so it *also* > forces DMA ops even if VIRTIO_F_IOMMU_PLATFORM is clear. > > Unfortunately as a result Xen never got around to > properly setting VIRTIO_F_IOMMU_PLATFO...

...IOMMU_PLATFORM, dma_ops should be > > > > > > used on Xen/x86 always and on Xen/ARM if Linux is Dom0 > > > > > > (because it has foreign > > > > > > mappings.) That is why we have the if (xen_domain) return > > > > > > true; in vring_use_dma_api. > > > > > > > > > > VIRTIO_F_IOMMU_PLATFORM makes guest always use DMA ops. > > > > > > > > > > Xen hack predates VIRTIO_F_IOMMU_PLATFORM so it *also* forces > > > > > DMA ops even if VIRTIO_F_IOMMU_PLATFORM is clear. >...

...IOMMU_PLATFORM, dma_ops should be > > > > > > used on Xen/x86 always and on Xen/ARM if Linux is Dom0 > > > > > > (because it has foreign > > > > > > mappings.) That is why we have the if (xen_domain) return > > > > > > true; in vring_use_dma_api. > > > > > > > > > > VIRTIO_F_IOMMU_PLATFORM makes guest always use DMA ops. > > > > > > > > > > Xen hack predates VIRTIO_F_IOMMU_PLATFORM so it *also* forces > > > > > DMA ops even if VIRTIO_F_IOMMU_PLATFORM is clear. >...