All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/5 v4] Fix virtio-blk issue with SWIOTLB
@ 2019-01-29  8:43 Joerg Roedel
  2019-01-29  8:43 ` [PATCH 1/5] swiotlb: Introduce swiotlb_max_mapping_size() Joerg Roedel
                   ` (9 more replies)
  0 siblings, 10 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-29  8:43 UTC (permalink / raw)
  To: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig
  Cc: Jens Axboe, virtualization, linux-block, linux-kernel, iommu,
	jfehlig, jon.grimm, brijesh.singh, joro, jroedel


Hi,

here is the fourth version of this patch-set. Previous
versions can be found here:

	V1: https://lore.kernel.org/lkml/20190110134433.15672-1-joro@8bytes.org/

	V2: https://lore.kernel.org/lkml/20190115132257.6426-1-joro@8bytes.org/

	V3: https://lore.kernel.org/lkml/20190123163049.24863-1-joro@8bytes.org/

The problem solved here is a limitation of the SWIOTLB implementation,
which does not support allocations larger than 256kb.  When the
virtio-blk driver tries to read/write a block larger than that, the
allocation of the dma-handle fails and an IO error is reported.

For all changes to v3, a diff to v3 of the patch-set is at
the end of this email.

Please review.

Thanks,

	Joerg

Joerg Roedel (5):
  swiotlb: Introduce swiotlb_max_mapping_size()
  swiotlb: Add is_swiotlb_active() function
  dma: Introduce dma_max_mapping_size()
  virtio: Introduce virtio_max_dma_size()
  virtio-blk: Consider virtio_max_dma_size() for maximum segment size

 Documentation/DMA-API.txt    |  8 ++++++++
 drivers/block/virtio_blk.c   | 10 ++++++----
 drivers/virtio/virtio_ring.c | 10 ++++++++++
 include/linux/dma-mapping.h  | 16 ++++++++++++++++
 include/linux/swiotlb.h      | 11 +++++++++++
 include/linux/virtio.h       |  2 ++
 kernel/dma/direct.c          | 11 +++++++++++
 kernel/dma/swiotlb.c         | 14 ++++++++++++++
 8 files changed, 78 insertions(+), 4 deletions(-)

-- 
2.17.1

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index e133ccd60228..acfe3d0f78d1 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -195,6 +195,14 @@ Requesting the required mask does not alter the current mask.  If you
 wish to take advantage of it, you should issue a dma_set_mask()
 call to set the mask to the value returned.
 
+::
+
+	size_t
+	dma_direct_max_mapping_size(struct device *dev);
+
+Returns the maximum size of a mapping for the device. The size parameter
+of the mapping functions like dma_map_single(), dma_map_page() and
+others should not be larger than the returned value.
 
 Part Id - Streaming DMA mappings
 --------------------------------
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 5c087d330b4b..e9e786b4b598 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -62,7 +62,7 @@ extern void swiotlb_tbl_sync_single(struct device *hwdev,
 
 extern int
 swiotlb_dma_supported(struct device *hwdev, u64 mask);
-extern size_t swiotlb_max_mapping_size(struct device *dev);
+size_t swiotlb_max_mapping_size(struct device *dev);
 bool is_swiotlb_active(void);
 
 #ifdef CONFIG_SWIOTLB
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 9fbd075081d9..c873f9cc2146 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -670,5 +670,9 @@ size_t swiotlb_max_mapping_size(struct device *dev)
 
 bool is_swiotlb_active(void)
 {
-	return !no_iotlb_memory;
+	/*
+	 * When SWIOTLB is initialized, even if io_tlb_start points to physical
+	 * address zero, io_tlb_end surely doesn't.
+	 */
+	return io_tlb_end != 0;
 }

^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 1/5] swiotlb: Introduce swiotlb_max_mapping_size()
  2019-01-29  8:43 [PATCH 0/5 v4] Fix virtio-blk issue with SWIOTLB Joerg Roedel
  2019-01-29  8:43 ` [PATCH 1/5] swiotlb: Introduce swiotlb_max_mapping_size() Joerg Roedel
@ 2019-01-29  8:43 ` Joerg Roedel
  2019-01-29 17:12   ` Christoph Hellwig
  2019-01-29 17:12   ` Christoph Hellwig
  2019-01-29  8:43 ` [PATCH 2/5] swiotlb: Add is_swiotlb_active() function Joerg Roedel
                   ` (7 subsequent siblings)
  9 siblings, 2 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-29  8:43 UTC (permalink / raw)
  To: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig
  Cc: Jens Axboe, virtualization, linux-block, linux-kernel, iommu,
	jfehlig, jon.grimm, brijesh.singh, joro, jroedel

From: Joerg Roedel <jroedel@suse.de>

The function returns the maximum size that can be remapped
by the SWIOTLB implementation. This function will be later
exposed to users through the DMA-API.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 include/linux/swiotlb.h | 5 +++++
 kernel/dma/swiotlb.c    | 5 +++++
 2 files changed, 10 insertions(+)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 7c007ed7505f..1c22d96e1742 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -62,6 +62,7 @@ extern void swiotlb_tbl_sync_single(struct device *hwdev,
 
 extern int
 swiotlb_dma_supported(struct device *hwdev, u64 mask);
+size_t swiotlb_max_mapping_size(struct device *dev);
 
 #ifdef CONFIG_SWIOTLB
 extern enum swiotlb_force swiotlb_force;
@@ -95,6 +96,10 @@ static inline unsigned int swiotlb_max_segment(void)
 {
 	return 0;
 }
+static inline size_t swiotlb_max_mapping_size(struct device *dev)
+{
+	return SIZE_MAX;
+}
 #endif /* CONFIG_SWIOTLB */
 
 extern void swiotlb_print_info(void);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 1fb6fd68b9c7..9cb21259cb0b 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -662,3 +662,8 @@ swiotlb_dma_supported(struct device *hwdev, u64 mask)
 {
 	return __phys_to_dma(hwdev, io_tlb_end - 1) <= mask;
 }
+
+size_t swiotlb_max_mapping_size(struct device *dev)
+{
+	return ((size_t)1 << IO_TLB_SHIFT) * IO_TLB_SEGSIZE;
+}
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 1/5] swiotlb: Introduce swiotlb_max_mapping_size()
  2019-01-29  8:43 [PATCH 0/5 v4] Fix virtio-blk issue with SWIOTLB Joerg Roedel
@ 2019-01-29  8:43 ` Joerg Roedel
  2019-01-29  8:43 ` Joerg Roedel
                   ` (8 subsequent siblings)
  9 siblings, 0 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-29  8:43 UTC (permalink / raw)
  To: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig
  Cc: Jens Axboe, jroedel, brijesh.singh, joro, jon.grimm, jfehlig,
	linux-kernel, linux-block, iommu, virtualization

From: Joerg Roedel <jroedel@suse.de>

The function returns the maximum size that can be remapped
by the SWIOTLB implementation. This function will be later
exposed to users through the DMA-API.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 include/linux/swiotlb.h | 5 +++++
 kernel/dma/swiotlb.c    | 5 +++++
 2 files changed, 10 insertions(+)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 7c007ed7505f..1c22d96e1742 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -62,6 +62,7 @@ extern void swiotlb_tbl_sync_single(struct device *hwdev,
 
 extern int
 swiotlb_dma_supported(struct device *hwdev, u64 mask);
+size_t swiotlb_max_mapping_size(struct device *dev);
 
 #ifdef CONFIG_SWIOTLB
 extern enum swiotlb_force swiotlb_force;
@@ -95,6 +96,10 @@ static inline unsigned int swiotlb_max_segment(void)
 {
 	return 0;
 }
+static inline size_t swiotlb_max_mapping_size(struct device *dev)
+{
+	return SIZE_MAX;
+}
 #endif /* CONFIG_SWIOTLB */
 
 extern void swiotlb_print_info(void);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 1fb6fd68b9c7..9cb21259cb0b 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -662,3 +662,8 @@ swiotlb_dma_supported(struct device *hwdev, u64 mask)
 {
 	return __phys_to_dma(hwdev, io_tlb_end - 1) <= mask;
 }
+
+size_t swiotlb_max_mapping_size(struct device *dev)
+{
+	return ((size_t)1 << IO_TLB_SHIFT) * IO_TLB_SEGSIZE;
+}
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-29  8:43 [PATCH 0/5 v4] Fix virtio-blk issue with SWIOTLB Joerg Roedel
                   ` (2 preceding siblings ...)
  2019-01-29  8:43 ` [PATCH 2/5] swiotlb: Add is_swiotlb_active() function Joerg Roedel
@ 2019-01-29  8:43 ` Joerg Roedel
  2019-01-29 17:12   ` Christoph Hellwig
  2019-01-29 17:12   ` Christoph Hellwig
  2019-01-29  8:43 ` [PATCH 3/5] dma: Introduce dma_max_mapping_size() Joerg Roedel
                   ` (5 subsequent siblings)
  9 siblings, 2 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-29  8:43 UTC (permalink / raw)
  To: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig
  Cc: Jens Axboe, virtualization, linux-block, linux-kernel, iommu,
	jfehlig, jon.grimm, brijesh.singh, joro, jroedel

From: Joerg Roedel <jroedel@suse.de>

This function will be used from dma_direct code to determine
the maximum segment size of a dma mapping.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 include/linux/swiotlb.h | 6 ++++++
 kernel/dma/swiotlb.c    | 9 +++++++++
 2 files changed, 15 insertions(+)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 1c22d96e1742..e9e786b4b598 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -63,6 +63,7 @@ extern void swiotlb_tbl_sync_single(struct device *hwdev,
 extern int
 swiotlb_dma_supported(struct device *hwdev, u64 mask);
 size_t swiotlb_max_mapping_size(struct device *dev);
+bool is_swiotlb_active(void);
 
 #ifdef CONFIG_SWIOTLB
 extern enum swiotlb_force swiotlb_force;
@@ -100,6 +101,11 @@ static inline size_t swiotlb_max_mapping_size(struct device *dev)
 {
 	return SIZE_MAX;
 }
+
+static inline bool is_swiotlb_active(void)
+{
+	return false;
+}
 #endif /* CONFIG_SWIOTLB */
 
 extern void swiotlb_print_info(void);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 9cb21259cb0b..c873f9cc2146 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -667,3 +667,12 @@ size_t swiotlb_max_mapping_size(struct device *dev)
 {
 	return ((size_t)1 << IO_TLB_SHIFT) * IO_TLB_SEGSIZE;
 }
+
+bool is_swiotlb_active(void)
+{
+	/*
+	 * When SWIOTLB is initialized, even if io_tlb_start points to physical
+	 * address zero, io_tlb_end surely doesn't.
+	 */
+	return io_tlb_end != 0;
+}
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-29  8:43 [PATCH 0/5 v4] Fix virtio-blk issue with SWIOTLB Joerg Roedel
  2019-01-29  8:43 ` [PATCH 1/5] swiotlb: Introduce swiotlb_max_mapping_size() Joerg Roedel
  2019-01-29  8:43 ` Joerg Roedel
@ 2019-01-29  8:43 ` Joerg Roedel
  2019-01-29  8:43 ` Joerg Roedel
                   ` (6 subsequent siblings)
  9 siblings, 0 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-29  8:43 UTC (permalink / raw)
  To: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig
  Cc: Jens Axboe, jroedel, brijesh.singh, joro, jon.grimm, jfehlig,
	linux-kernel, linux-block, iommu, virtualization

From: Joerg Roedel <jroedel@suse.de>

This function will be used from dma_direct code to determine
the maximum segment size of a dma mapping.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 include/linux/swiotlb.h | 6 ++++++
 kernel/dma/swiotlb.c    | 9 +++++++++
 2 files changed, 15 insertions(+)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 1c22d96e1742..e9e786b4b598 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -63,6 +63,7 @@ extern void swiotlb_tbl_sync_single(struct device *hwdev,
 extern int
 swiotlb_dma_supported(struct device *hwdev, u64 mask);
 size_t swiotlb_max_mapping_size(struct device *dev);
+bool is_swiotlb_active(void);
 
 #ifdef CONFIG_SWIOTLB
 extern enum swiotlb_force swiotlb_force;
@@ -100,6 +101,11 @@ static inline size_t swiotlb_max_mapping_size(struct device *dev)
 {
 	return SIZE_MAX;
 }
+
+static inline bool is_swiotlb_active(void)
+{
+	return false;
+}
 #endif /* CONFIG_SWIOTLB */
 
 extern void swiotlb_print_info(void);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 9cb21259cb0b..c873f9cc2146 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -667,3 +667,12 @@ size_t swiotlb_max_mapping_size(struct device *dev)
 {
 	return ((size_t)1 << IO_TLB_SHIFT) * IO_TLB_SEGSIZE;
 }
+
+bool is_swiotlb_active(void)
+{
+	/*
+	 * When SWIOTLB is initialized, even if io_tlb_start points to physical
+	 * address zero, io_tlb_end surely doesn't.
+	 */
+	return io_tlb_end != 0;
+}
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 3/5] dma: Introduce dma_max_mapping_size()
  2019-01-29  8:43 [PATCH 0/5 v4] Fix virtio-blk issue with SWIOTLB Joerg Roedel
                   ` (4 preceding siblings ...)
  2019-01-29  8:43 ` [PATCH 3/5] dma: Introduce dma_max_mapping_size() Joerg Roedel
@ 2019-01-29  8:43 ` Joerg Roedel
  2019-01-29 17:13   ` Christoph Hellwig
                     ` (3 more replies)
  2019-01-29  8:43 ` [PATCH 4/5] virtio: Introduce virtio_max_dma_size() Joerg Roedel
                   ` (3 subsequent siblings)
  9 siblings, 4 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-29  8:43 UTC (permalink / raw)
  To: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig
  Cc: Jens Axboe, virtualization, linux-block, linux-kernel, iommu,
	jfehlig, jon.grimm, brijesh.singh, joro, jroedel

From: Joerg Roedel <jroedel@suse.de>

The function returns the maximum size that can be mapped
using DMA-API functions. The patch also adds the
implementation for direct DMA and a new dma_map_ops pointer
so that other implementations can expose their limit.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 Documentation/DMA-API.txt   |  8 ++++++++
 include/linux/dma-mapping.h | 16 ++++++++++++++++
 kernel/dma/direct.c         | 11 +++++++++++
 3 files changed, 35 insertions(+)

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index e133ccd60228..acfe3d0f78d1 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -195,6 +195,14 @@ Requesting the required mask does not alter the current mask.  If you
 wish to take advantage of it, you should issue a dma_set_mask()
 call to set the mask to the value returned.
 
+::
+
+	size_t
+	dma_direct_max_mapping_size(struct device *dev);
+
+Returns the maximum size of a mapping for the device. The size parameter
+of the mapping functions like dma_map_single(), dma_map_page() and
+others should not be larger than the returned value.
 
 Part Id - Streaming DMA mappings
 --------------------------------
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f6ded992c183..a3ca8a71a704 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -130,6 +130,7 @@ struct dma_map_ops {
 			enum dma_data_direction direction);
 	int (*dma_supported)(struct device *dev, u64 mask);
 	u64 (*get_required_mask)(struct device *dev);
+	size_t (*max_mapping_size)(struct device *dev);
 };
 
 #define DMA_MAPPING_ERROR		(~(dma_addr_t)0)
@@ -257,6 +258,8 @@ static inline void dma_direct_sync_sg_for_cpu(struct device *dev,
 }
 #endif
 
+size_t dma_direct_max_mapping_size(struct device *dev);
+
 #ifdef CONFIG_HAS_DMA
 #include <asm/dma-mapping.h>
 
@@ -440,6 +443,19 @@ static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
 	return 0;
 }
 
+static inline size_t dma_max_mapping_size(struct device *dev)
+{
+	const struct dma_map_ops *ops = get_dma_ops(dev);
+	size_t size = SIZE_MAX;
+
+	if (dma_is_direct(ops))
+		size = dma_direct_max_mapping_size(dev);
+	else if (ops && ops->max_mapping_size)
+		size = ops->max_mapping_size(dev);
+
+	return size;
+}
+
 void *dma_alloc_attrs(struct device *dev, size_t size, dma_addr_t *dma_handle,
 		gfp_t flag, unsigned long attrs);
 void dma_free_attrs(struct device *dev, size_t size, void *cpu_addr,
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 355d16acee6d..6310ad01f915 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -380,3 +380,14 @@ int dma_direct_supported(struct device *dev, u64 mask)
 	 */
 	return mask >= __phys_to_dma(dev, min_mask);
 }
+
+size_t dma_direct_max_mapping_size(struct device *dev)
+{
+	size_t size = SIZE_MAX;
+
+	/* If SWIOTLB is active, use its maximum mapping size */
+	if (is_swiotlb_active())
+		size = swiotlb_max_mapping_size(dev);
+
+	return size;
+}
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 3/5] dma: Introduce dma_max_mapping_size()
  2019-01-29  8:43 [PATCH 0/5 v4] Fix virtio-blk issue with SWIOTLB Joerg Roedel
                   ` (3 preceding siblings ...)
  2019-01-29  8:43 ` Joerg Roedel
@ 2019-01-29  8:43 ` Joerg Roedel
  2019-01-29  8:43 ` Joerg Roedel
                   ` (4 subsequent siblings)
  9 siblings, 0 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-29  8:43 UTC (permalink / raw)
  To: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig
  Cc: Jens Axboe, jroedel, brijesh.singh, joro, jon.grimm, jfehlig,
	linux-kernel, linux-block, iommu, virtualization

From: Joerg Roedel <jroedel@suse.de>

The function returns the maximum size that can be mapped
using DMA-API functions. The patch also adds the
implementation for direct DMA and a new dma_map_ops pointer
so that other implementations can expose their limit.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 Documentation/DMA-API.txt   |  8 ++++++++
 include/linux/dma-mapping.h | 16 ++++++++++++++++
 kernel/dma/direct.c         | 11 +++++++++++
 3 files changed, 35 insertions(+)

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index e133ccd60228..acfe3d0f78d1 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -195,6 +195,14 @@ Requesting the required mask does not alter the current mask.  If you
 wish to take advantage of it, you should issue a dma_set_mask()
 call to set the mask to the value returned.
 
+::
+
+	size_t
+	dma_direct_max_mapping_size(struct device *dev);
+
+Returns the maximum size of a mapping for the device. The size parameter
+of the mapping functions like dma_map_single(), dma_map_page() and
+others should not be larger than the returned value.
 
 Part Id - Streaming DMA mappings
 --------------------------------
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f6ded992c183..a3ca8a71a704 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -130,6 +130,7 @@ struct dma_map_ops {
 			enum dma_data_direction direction);
 	int (*dma_supported)(struct device *dev, u64 mask);
 	u64 (*get_required_mask)(struct device *dev);
+	size_t (*max_mapping_size)(struct device *dev);
 };
 
 #define DMA_MAPPING_ERROR		(~(dma_addr_t)0)
@@ -257,6 +258,8 @@ static inline void dma_direct_sync_sg_for_cpu(struct device *dev,
 }
 #endif
 
+size_t dma_direct_max_mapping_size(struct device *dev);
+
 #ifdef CONFIG_HAS_DMA
 #include <asm/dma-mapping.h>
 
@@ -440,6 +443,19 @@ static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
 	return 0;
 }
 
+static inline size_t dma_max_mapping_size(struct device *dev)
+{
+	const struct dma_map_ops *ops = get_dma_ops(dev);
+	size_t size = SIZE_MAX;
+
+	if (dma_is_direct(ops))
+		size = dma_direct_max_mapping_size(dev);
+	else if (ops && ops->max_mapping_size)
+		size = ops->max_mapping_size(dev);
+
+	return size;
+}
+
 void *dma_alloc_attrs(struct device *dev, size_t size, dma_addr_t *dma_handle,
 		gfp_t flag, unsigned long attrs);
 void dma_free_attrs(struct device *dev, size_t size, void *cpu_addr,
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 355d16acee6d..6310ad01f915 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -380,3 +380,14 @@ int dma_direct_supported(struct device *dev, u64 mask)
 	 */
 	return mask >= __phys_to_dma(dev, min_mask);
 }
+
+size_t dma_direct_max_mapping_size(struct device *dev)
+{
+	size_t size = SIZE_MAX;
+
+	/* If SWIOTLB is active, use its maximum mapping size */
+	if (is_swiotlb_active())
+		size = swiotlb_max_mapping_size(dev);
+
+	return size;
+}
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 4/5] virtio: Introduce virtio_max_dma_size()
  2019-01-29  8:43 [PATCH 0/5 v4] Fix virtio-blk issue with SWIOTLB Joerg Roedel
                   ` (6 preceding siblings ...)
  2019-01-29  8:43 ` [PATCH 4/5] virtio: Introduce virtio_max_dma_size() Joerg Roedel
@ 2019-01-29  8:43 ` Joerg Roedel
  2019-01-29 17:13   ` Christoph Hellwig
                     ` (3 more replies)
  2019-01-29  8:43 ` [PATCH 5/5] virtio-blk: Consider virtio_max_dma_size() for maximum segment size Joerg Roedel
  2019-01-29  8:43 ` Joerg Roedel
  9 siblings, 4 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-29  8:43 UTC (permalink / raw)
  To: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig
  Cc: Jens Axboe, virtualization, linux-block, linux-kernel, iommu,
	jfehlig, jon.grimm, brijesh.singh, joro, jroedel

From: Joerg Roedel <jroedel@suse.de>

This function returns the maximum segment size for a single
dma transaction of a virtio device. The possible limit comes
from the SWIOTLB implementation in the Linux kernel, that
has an upper limit of (currently) 256kb of contiguous
memory it can map. Other DMA-API implementations might also
have limits.

Use the new dma_max_mapping_size() function to determine the
maximum mapping size when DMA-API is in use for virtio.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 drivers/virtio/virtio_ring.c | 10 ++++++++++
 include/linux/virtio.h       |  2 ++
 2 files changed, 12 insertions(+)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index cd7e755484e3..9ca3fe6af9fa 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -266,6 +266,16 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
 	return false;
 }
 
+size_t virtio_max_dma_size(struct virtio_device *vdev)
+{
+	size_t max_segment_size = SIZE_MAX;
+
+	if (vring_use_dma_api(vdev))
+		max_segment_size = dma_max_mapping_size(&vdev->dev);
+
+	return max_segment_size;
+}
+
 static void *vring_alloc_queue(struct virtio_device *vdev, size_t size,
 			      dma_addr_t *dma_handle, gfp_t flag)
 {
diff --git a/include/linux/virtio.h b/include/linux/virtio.h
index fa1b5da2804e..673fe3ef3607 100644
--- a/include/linux/virtio.h
+++ b/include/linux/virtio.h
@@ -157,6 +157,8 @@ int virtio_device_freeze(struct virtio_device *dev);
 int virtio_device_restore(struct virtio_device *dev);
 #endif
 
+size_t virtio_max_dma_size(struct virtio_device *vdev);
+
 #define virtio_device_for_each_vq(vdev, vq) \
 	list_for_each_entry(vq, &vdev->vqs, list)
 
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 4/5] virtio: Introduce virtio_max_dma_size()
  2019-01-29  8:43 [PATCH 0/5 v4] Fix virtio-blk issue with SWIOTLB Joerg Roedel
                   ` (5 preceding siblings ...)
  2019-01-29  8:43 ` Joerg Roedel
@ 2019-01-29  8:43 ` Joerg Roedel
  2019-01-29  8:43 ` Joerg Roedel
                   ` (2 subsequent siblings)
  9 siblings, 0 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-29  8:43 UTC (permalink / raw)
  To: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig
  Cc: Jens Axboe, jroedel, brijesh.singh, joro, jon.grimm, jfehlig,
	linux-kernel, linux-block, iommu, virtualization

From: Joerg Roedel <jroedel@suse.de>

This function returns the maximum segment size for a single
dma transaction of a virtio device. The possible limit comes
from the SWIOTLB implementation in the Linux kernel, that
has an upper limit of (currently) 256kb of contiguous
memory it can map. Other DMA-API implementations might also
have limits.

Use the new dma_max_mapping_size() function to determine the
maximum mapping size when DMA-API is in use for virtio.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 drivers/virtio/virtio_ring.c | 10 ++++++++++
 include/linux/virtio.h       |  2 ++
 2 files changed, 12 insertions(+)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index cd7e755484e3..9ca3fe6af9fa 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -266,6 +266,16 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
 	return false;
 }
 
+size_t virtio_max_dma_size(struct virtio_device *vdev)
+{
+	size_t max_segment_size = SIZE_MAX;
+
+	if (vring_use_dma_api(vdev))
+		max_segment_size = dma_max_mapping_size(&vdev->dev);
+
+	return max_segment_size;
+}
+
 static void *vring_alloc_queue(struct virtio_device *vdev, size_t size,
 			      dma_addr_t *dma_handle, gfp_t flag)
 {
diff --git a/include/linux/virtio.h b/include/linux/virtio.h
index fa1b5da2804e..673fe3ef3607 100644
--- a/include/linux/virtio.h
+++ b/include/linux/virtio.h
@@ -157,6 +157,8 @@ int virtio_device_freeze(struct virtio_device *dev);
 int virtio_device_restore(struct virtio_device *dev);
 #endif
 
+size_t virtio_max_dma_size(struct virtio_device *vdev);
+
 #define virtio_device_for_each_vq(vdev, vq) \
 	list_for_each_entry(vq, &vdev->vqs, list)
 
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 5/5] virtio-blk: Consider virtio_max_dma_size() for maximum segment size
  2019-01-29  8:43 [PATCH 0/5 v4] Fix virtio-blk issue with SWIOTLB Joerg Roedel
                   ` (8 preceding siblings ...)
  2019-01-29  8:43 ` [PATCH 5/5] virtio-blk: Consider virtio_max_dma_size() for maximum segment size Joerg Roedel
@ 2019-01-29  8:43 ` Joerg Roedel
  2019-01-29 17:13   ` Christoph Hellwig
  2019-01-29 17:13   ` Christoph Hellwig
  9 siblings, 2 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-29  8:43 UTC (permalink / raw)
  To: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig
  Cc: Jens Axboe, virtualization, linux-block, linux-kernel, iommu,
	jfehlig, jon.grimm, brijesh.singh, joro, jroedel

From: Joerg Roedel <jroedel@suse.de>

Segments can't be larger than the maximum DMA mapping size
supported on the platform. Take that into account when
setting the maximum segment size for a block device.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 drivers/block/virtio_blk.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index b16a887bbd02..4bc083b7c9b5 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -723,7 +723,7 @@ static int virtblk_probe(struct virtio_device *vdev)
 	struct request_queue *q;
 	int err, index;
 
-	u32 v, blk_size, sg_elems, opt_io_size;
+	u32 v, blk_size, max_size, sg_elems, opt_io_size;
 	u16 min_io_size;
 	u8 physical_block_exp, alignment_offset;
 
@@ -826,14 +826,16 @@ static int virtblk_probe(struct virtio_device *vdev)
 	/* No real sector limit. */
 	blk_queue_max_hw_sectors(q, -1U);
 
+	max_size = virtio_max_dma_size(vdev);
+
 	/* Host can optionally specify maximum segment size and number of
 	 * segments. */
 	err = virtio_cread_feature(vdev, VIRTIO_BLK_F_SIZE_MAX,
 				   struct virtio_blk_config, size_max, &v);
 	if (!err)
-		blk_queue_max_segment_size(q, v);
-	else
-		blk_queue_max_segment_size(q, -1U);
+		max_size = min(max_size, v);
+
+	blk_queue_max_segment_size(q, max_size);
 
 	/* Host can optionally specify the block size of the device */
 	err = virtio_cread_feature(vdev, VIRTIO_BLK_F_BLK_SIZE,
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 5/5] virtio-blk: Consider virtio_max_dma_size() for maximum segment size
  2019-01-29  8:43 [PATCH 0/5 v4] Fix virtio-blk issue with SWIOTLB Joerg Roedel
                   ` (7 preceding siblings ...)
  2019-01-29  8:43 ` Joerg Roedel
@ 2019-01-29  8:43 ` Joerg Roedel
  2019-01-29  8:43 ` Joerg Roedel
  9 siblings, 0 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-29  8:43 UTC (permalink / raw)
  To: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig
  Cc: Jens Axboe, jroedel, brijesh.singh, joro, jon.grimm, jfehlig,
	linux-kernel, linux-block, iommu, virtualization

From: Joerg Roedel <jroedel@suse.de>

Segments can't be larger than the maximum DMA mapping size
supported on the platform. Take that into account when
setting the maximum segment size for a block device.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 drivers/block/virtio_blk.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index b16a887bbd02..4bc083b7c9b5 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -723,7 +723,7 @@ static int virtblk_probe(struct virtio_device *vdev)
 	struct request_queue *q;
 	int err, index;
 
-	u32 v, blk_size, sg_elems, opt_io_size;
+	u32 v, blk_size, max_size, sg_elems, opt_io_size;
 	u16 min_io_size;
 	u8 physical_block_exp, alignment_offset;
 
@@ -826,14 +826,16 @@ static int virtblk_probe(struct virtio_device *vdev)
 	/* No real sector limit. */
 	blk_queue_max_hw_sectors(q, -1U);
 
+	max_size = virtio_max_dma_size(vdev);
+
 	/* Host can optionally specify maximum segment size and number of
 	 * segments. */
 	err = virtio_cread_feature(vdev, VIRTIO_BLK_F_SIZE_MAX,
 				   struct virtio_blk_config, size_max, &v);
 	if (!err)
-		blk_queue_max_segment_size(q, v);
-	else
-		blk_queue_max_segment_size(q, -1U);
+		max_size = min(max_size, v);
+
+	blk_queue_max_segment_size(q, max_size);
 
 	/* Host can optionally specify the block size of the device */
 	err = virtio_cread_feature(vdev, VIRTIO_BLK_F_BLK_SIZE,
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 47+ messages in thread

* Re: [PATCH 1/5] swiotlb: Introduce swiotlb_max_mapping_size()
  2019-01-29  8:43 ` Joerg Roedel
  2019-01-29 17:12   ` Christoph Hellwig
@ 2019-01-29 17:12   ` Christoph Hellwig
  1 sibling, 0 replies; 47+ messages in thread
From: Christoph Hellwig @ 2019-01-29 17:12 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig, Jens Axboe, virtualization, linux-block,
	linux-kernel, iommu, jfehlig, jon.grimm, brijesh.singh, jroedel

On Tue, Jan 29, 2019 at 09:43:38AM +0100, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> The function returns the maximum size that can be remapped
> by the SWIOTLB implementation. This function will be later
> exposed to users through the DMA-API.
> 
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 1/5] swiotlb: Introduce swiotlb_max_mapping_size()
  2019-01-29  8:43 ` Joerg Roedel
@ 2019-01-29 17:12   ` Christoph Hellwig
  2019-01-29 17:12   ` Christoph Hellwig
  1 sibling, 0 replies; 47+ messages in thread
From: Christoph Hellwig @ 2019-01-29 17:12 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Jens Axboe, jon.grimm, brijesh.singh, Konrad Rzeszutek Wilk,
	Michael S . Tsirkin, jfehlig, linux-kernel, virtualization,
	linux-block, iommu, jroedel, Christoph Hellwig

On Tue, Jan 29, 2019 at 09:43:38AM +0100, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> The function returns the maximum size that can be remapped
> by the SWIOTLB implementation. This function will be later
> exposed to users through the DMA-API.
> 
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-29  8:43 ` Joerg Roedel
@ 2019-01-29 17:12   ` Christoph Hellwig
  2019-01-29 17:12   ` Christoph Hellwig
  1 sibling, 0 replies; 47+ messages in thread
From: Christoph Hellwig @ 2019-01-29 17:12 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig, Jens Axboe, virtualization, linux-block,
	linux-kernel, iommu, jfehlig, jon.grimm, brijesh.singh, jroedel

On Tue, Jan 29, 2019 at 09:43:39AM +0100, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> This function will be used from dma_direct code to determine
> the maximum segment size of a dma mapping.
> 
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>

Looks good,

Reviewed-by: Christoph Hellwig <hch@lst.de>

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-29  8:43 ` Joerg Roedel
  2019-01-29 17:12   ` Christoph Hellwig
@ 2019-01-29 17:12   ` Christoph Hellwig
  1 sibling, 0 replies; 47+ messages in thread
From: Christoph Hellwig @ 2019-01-29 17:12 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Jens Axboe, jon.grimm, brijesh.singh, Konrad Rzeszutek Wilk,
	Michael S . Tsirkin, jfehlig, linux-kernel, virtualization,
	linux-block, iommu, jroedel, Christoph Hellwig

On Tue, Jan 29, 2019 at 09:43:39AM +0100, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> This function will be used from dma_direct code to determine
> the maximum segment size of a dma mapping.
> 
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>

Looks good,

Reviewed-by: Christoph Hellwig <hch@lst.de>

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 3/5] dma: Introduce dma_max_mapping_size()
  2019-01-29  8:43 ` Joerg Roedel
  2019-01-29 17:13   ` Christoph Hellwig
@ 2019-01-29 17:13   ` Christoph Hellwig
  2019-01-30 15:09   ` Lendacky, Thomas
  2019-01-30 15:09     ` Lendacky, Thomas
  3 siblings, 0 replies; 47+ messages in thread
From: Christoph Hellwig @ 2019-01-29 17:13 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig, Jens Axboe, virtualization, linux-block,
	linux-kernel, iommu, jfehlig, jon.grimm, brijesh.singh, jroedel

On Tue, Jan 29, 2019 at 09:43:40AM +0100, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> The function returns the maximum size that can be mapped
> using DMA-API functions. The patch also adds the
> implementation for direct DMA and a new dma_map_ops pointer
> so that other implementations can expose their limit.
> 
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 3/5] dma: Introduce dma_max_mapping_size()
  2019-01-29  8:43 ` Joerg Roedel
@ 2019-01-29 17:13   ` Christoph Hellwig
  2019-01-29 17:13   ` Christoph Hellwig
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 47+ messages in thread
From: Christoph Hellwig @ 2019-01-29 17:13 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Jens Axboe, jon.grimm, brijesh.singh, Konrad Rzeszutek Wilk,
	Michael S . Tsirkin, jfehlig, linux-kernel, virtualization,
	linux-block, iommu, jroedel, Christoph Hellwig

On Tue, Jan 29, 2019 at 09:43:40AM +0100, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> The function returns the maximum size that can be mapped
> using DMA-API functions. The patch also adds the
> implementation for direct DMA and a new dma_map_ops pointer
> so that other implementations can expose their limit.
> 
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 4/5] virtio: Introduce virtio_max_dma_size()
  2019-01-29  8:43 ` Joerg Roedel
  2019-01-29 17:13   ` Christoph Hellwig
@ 2019-01-29 17:13   ` Christoph Hellwig
  2019-01-30 15:10   ` Lendacky, Thomas
  2019-01-30 15:10     ` Lendacky, Thomas
  3 siblings, 0 replies; 47+ messages in thread
From: Christoph Hellwig @ 2019-01-29 17:13 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig, Jens Axboe, virtualization, linux-block,
	linux-kernel, iommu, jfehlig, jon.grimm, brijesh.singh, jroedel

On Tue, Jan 29, 2019 at 09:43:41AM +0100, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> This function returns the maximum segment size for a single
> dma transaction of a virtio device. The possible limit comes
> from the SWIOTLB implementation in the Linux kernel, that
> has an upper limit of (currently) 256kb of contiguous
> memory it can map. Other DMA-API implementations might also
> have limits.
> 
> Use the new dma_max_mapping_size() function to determine the
> maximum mapping size when DMA-API is in use for virtio.
> 
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>

Looks good,

Reviewed-by: Christoph Hellwig <hch@lst.de>

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 4/5] virtio: Introduce virtio_max_dma_size()
  2019-01-29  8:43 ` Joerg Roedel
@ 2019-01-29 17:13   ` Christoph Hellwig
  2019-01-29 17:13   ` Christoph Hellwig
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 47+ messages in thread
From: Christoph Hellwig @ 2019-01-29 17:13 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Jens Axboe, jon.grimm, brijesh.singh, Konrad Rzeszutek Wilk,
	Michael S . Tsirkin, jfehlig, linux-kernel, virtualization,
	linux-block, iommu, jroedel, Christoph Hellwig

On Tue, Jan 29, 2019 at 09:43:41AM +0100, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> This function returns the maximum segment size for a single
> dma transaction of a virtio device. The possible limit comes
> from the SWIOTLB implementation in the Linux kernel, that
> has an upper limit of (currently) 256kb of contiguous
> memory it can map. Other DMA-API implementations might also
> have limits.
> 
> Use the new dma_max_mapping_size() function to determine the
> maximum mapping size when DMA-API is in use for virtio.
> 
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>

Looks good,

Reviewed-by: Christoph Hellwig <hch@lst.de>

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 5/5] virtio-blk: Consider virtio_max_dma_size() for maximum segment size
  2019-01-29  8:43 ` Joerg Roedel
  2019-01-29 17:13   ` Christoph Hellwig
@ 2019-01-29 17:13   ` Christoph Hellwig
  1 sibling, 0 replies; 47+ messages in thread
From: Christoph Hellwig @ 2019-01-29 17:13 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig, Jens Axboe, virtualization, linux-block,
	linux-kernel, iommu, jfehlig, jon.grimm, brijesh.singh, jroedel

On Tue, Jan 29, 2019 at 09:43:42AM +0100, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> Segments can't be larger than the maximum DMA mapping size
> supported on the platform. Take that into account when
> setting the maximum segment size for a block device.
> 
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 5/5] virtio-blk: Consider virtio_max_dma_size() for maximum segment size
  2019-01-29  8:43 ` Joerg Roedel
@ 2019-01-29 17:13   ` Christoph Hellwig
  2019-01-29 17:13   ` Christoph Hellwig
  1 sibling, 0 replies; 47+ messages in thread
From: Christoph Hellwig @ 2019-01-29 17:13 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Jens Axboe, jon.grimm, brijesh.singh, Konrad Rzeszutek Wilk,
	Michael S . Tsirkin, jfehlig, linux-kernel, virtualization,
	linux-block, iommu, jroedel, Christoph Hellwig

On Tue, Jan 29, 2019 at 09:43:42AM +0100, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> Segments can't be larger than the maximum DMA mapping size
> supported on the platform. Take that into account when
> setting the maximum segment size for a block device.
> 
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 3/5] dma: Introduce dma_max_mapping_size()
  2019-01-29  8:43 ` Joerg Roedel
@ 2019-01-30 15:09     ` Lendacky, Thomas
  2019-01-29 17:13   ` Christoph Hellwig
                       ` (2 subsequent siblings)
  3 siblings, 0 replies; 47+ messages in thread
From: Lendacky, Thomas @ 2019-01-30 15:09 UTC (permalink / raw)
  To: Joerg Roedel, Michael S . Tsirkin, Jason Wang,
	Konrad Rzeszutek Wilk, Christoph Hellwig
  Cc: Jens Axboe, virtualization, linux-block, linux-kernel, iommu,
	jfehlig, Grimm, Jon, Singh, Brijesh, jroedel

On 1/29/19 2:43 AM, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> The function returns the maximum size that can be mapped
> using DMA-API functions. The patch also adds the
> implementation for direct DMA and a new dma_map_ops pointer
> so that other implementations can expose their limit.
> 
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
> ---
>  Documentation/DMA-API.txt   |  8 ++++++++
>  include/linux/dma-mapping.h | 16 ++++++++++++++++
>  kernel/dma/direct.c         | 11 +++++++++++
>  3 files changed, 35 insertions(+)
> 
> diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
> index e133ccd60228..acfe3d0f78d1 100644
> --- a/Documentation/DMA-API.txt
> +++ b/Documentation/DMA-API.txt
> @@ -195,6 +195,14 @@ Requesting the required mask does not alter the current mask.  If you
>  wish to take advantage of it, you should issue a dma_set_mask()
>  call to set the mask to the value returned.
>  
> +::
> +
> +	size_t
> +	dma_direct_max_mapping_size(struct device *dev);
> +
> +Returns the maximum size of a mapping for the device. The size parameter
> +of the mapping functions like dma_map_single(), dma_map_page() and
> +others should not be larger than the returned value.
>  
>  Part Id - Streaming DMA mappings
>  --------------------------------
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index f6ded992c183..a3ca8a71a704 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -130,6 +130,7 @@ struct dma_map_ops {
>  			enum dma_data_direction direction);
>  	int (*dma_supported)(struct device *dev, u64 mask);
>  	u64 (*get_required_mask)(struct device *dev);
> +	size_t (*max_mapping_size)(struct device *dev);
>  };
>  
>  #define DMA_MAPPING_ERROR		(~(dma_addr_t)0)
> @@ -257,6 +258,8 @@ static inline void dma_direct_sync_sg_for_cpu(struct device *dev,
>  }
>  #endif
>  
> +size_t dma_direct_max_mapping_size(struct device *dev);
> +
>  #ifdef CONFIG_HAS_DMA
>  #include <asm/dma-mapping.h>
>  
> @@ -440,6 +443,19 @@ static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
>  	return 0;
>  }
>  
> +static inline size_t dma_max_mapping_size(struct device *dev)
> +{
> +	const struct dma_map_ops *ops = get_dma_ops(dev);
> +	size_t size = SIZE_MAX;
> +
> +	if (dma_is_direct(ops))
> +		size = dma_direct_max_mapping_size(dev);
> +	else if (ops && ops->max_mapping_size)
> +		size = ops->max_mapping_size(dev);
> +
> +	return size;
> +}
> +
>  void *dma_alloc_attrs(struct device *dev, size_t size, dma_addr_t *dma_handle,
>  		gfp_t flag, unsigned long attrs);
>  void dma_free_attrs(struct device *dev, size_t size, void *cpu_addr,
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 355d16acee6d..6310ad01f915 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -380,3 +380,14 @@ int dma_direct_supported(struct device *dev, u64 mask)
>  	 */
>  	return mask >= __phys_to_dma(dev, min_mask);
>  }
> +
> +size_t dma_direct_max_mapping_size(struct device *dev)
> +{
> +	size_t size = SIZE_MAX;
> +
> +	/* If SWIOTLB is active, use its maximum mapping size */
> +	if (is_swiotlb_active())
> +		size = swiotlb_max_mapping_size(dev);
> +
> +	return size;
> +}

When I build with these patches and with the virtio devices as modules I
get a build failure. Looks like this needs an EXPORT_SYMBOL() (I'm
assuming EXPORT_SYMBOL for DMA functions and not EXPORT_SYMBOL_GPL?).

Thanks,
Tom

> 

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 3/5] dma: Introduce dma_max_mapping_size()
@ 2019-01-30 15:09     ` Lendacky, Thomas
  0 siblings, 0 replies; 47+ messages in thread
From: Lendacky, Thomas @ 2019-01-30 15:09 UTC (permalink / raw)
  To: Joerg Roedel, Michael S . Tsirkin, Jason Wang,
	Konrad Rzeszutek Wilk, Christoph Hellwig
  Cc: Jens Axboe, virtualization, linux-block, linux-kernel, iommu,
	jfehlig, Grimm, Jon, Singh, Brijesh, jroedel

On 1/29/19 2:43 AM, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> The function returns the maximum size that can be mapped
> using DMA-API functions. The patch also adds the
> implementation for direct DMA and a new dma_map_ops pointer
> so that other implementations can expose their limit.
> 
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
> ---
>  Documentation/DMA-API.txt   |  8 ++++++++
>  include/linux/dma-mapping.h | 16 ++++++++++++++++
>  kernel/dma/direct.c         | 11 +++++++++++
>  3 files changed, 35 insertions(+)
> 
> diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
> index e133ccd60228..acfe3d0f78d1 100644
> --- a/Documentation/DMA-API.txt
> +++ b/Documentation/DMA-API.txt
> @@ -195,6 +195,14 @@ Requesting the required mask does not alter the current mask.  If you
>  wish to take advantage of it, you should issue a dma_set_mask()
>  call to set the mask to the value returned.
>  
> +::
> +
> +	size_t
> +	dma_direct_max_mapping_size(struct device *dev);
> +
> +Returns the maximum size of a mapping for the device. The size parameter
> +of the mapping functions like dma_map_single(), dma_map_page() and
> +others should not be larger than the returned value.
>  
>  Part Id - Streaming DMA mappings
>  --------------------------------
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index f6ded992c183..a3ca8a71a704 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -130,6 +130,7 @@ struct dma_map_ops {
>  			enum dma_data_direction direction);
>  	int (*dma_supported)(struct device *dev, u64 mask);
>  	u64 (*get_required_mask)(struct device *dev);
> +	size_t (*max_mapping_size)(struct device *dev);
>  };
>  
>  #define DMA_MAPPING_ERROR		(~(dma_addr_t)0)
> @@ -257,6 +258,8 @@ static inline void dma_direct_sync_sg_for_cpu(struct device *dev,
>  }
>  #endif
>  
> +size_t dma_direct_max_mapping_size(struct device *dev);
> +
>  #ifdef CONFIG_HAS_DMA
>  #include <asm/dma-mapping.h>
>  
> @@ -440,6 +443,19 @@ static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
>  	return 0;
>  }
>  
> +static inline size_t dma_max_mapping_size(struct device *dev)
> +{
> +	const struct dma_map_ops *ops = get_dma_ops(dev);
> +	size_t size = SIZE_MAX;
> +
> +	if (dma_is_direct(ops))
> +		size = dma_direct_max_mapping_size(dev);
> +	else if (ops && ops->max_mapping_size)
> +		size = ops->max_mapping_size(dev);
> +
> +	return size;
> +}
> +
>  void *dma_alloc_attrs(struct device *dev, size_t size, dma_addr_t *dma_handle,
>  		gfp_t flag, unsigned long attrs);
>  void dma_free_attrs(struct device *dev, size_t size, void *cpu_addr,
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 355d16acee6d..6310ad01f915 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -380,3 +380,14 @@ int dma_direct_supported(struct device *dev, u64 mask)
>  	 */
>  	return mask >= __phys_to_dma(dev, min_mask);
>  }
> +
> +size_t dma_direct_max_mapping_size(struct device *dev)
> +{
> +	size_t size = SIZE_MAX;
> +
> +	/* If SWIOTLB is active, use its maximum mapping size */
> +	if (is_swiotlb_active())
> +		size = swiotlb_max_mapping_size(dev);
> +
> +	return size;
> +}

When I build with these patches and with the virtio devices as modules I
get a build failure. Looks like this needs an EXPORT_SYMBOL() (I'm
assuming EXPORT_SYMBOL for DMA functions and not EXPORT_SYMBOL_GPL?).

Thanks,
Tom

> 

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 3/5] dma: Introduce dma_max_mapping_size()
  2019-01-29  8:43 ` Joerg Roedel
  2019-01-29 17:13   ` Christoph Hellwig
  2019-01-29 17:13   ` Christoph Hellwig
@ 2019-01-30 15:09   ` Lendacky, Thomas
  2019-01-30 15:09     ` Lendacky, Thomas
  3 siblings, 0 replies; 47+ messages in thread
From: Lendacky, Thomas @ 2019-01-30 15:09 UTC (permalink / raw)
  To: Joerg Roedel, Michael S . Tsirkin, Jason Wang,
	Konrad Rzeszutek Wilk, Christoph Hellwig
  Cc: Jens Axboe, jroedel, Singh, Brijesh, Grimm, Jon, jfehlig,
	linux-kernel, linux-block, iommu, virtualization

On 1/29/19 2:43 AM, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> The function returns the maximum size that can be mapped
> using DMA-API functions. The patch also adds the
> implementation for direct DMA and a new dma_map_ops pointer
> so that other implementations can expose their limit.
> 
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
> ---
>  Documentation/DMA-API.txt   |  8 ++++++++
>  include/linux/dma-mapping.h | 16 ++++++++++++++++
>  kernel/dma/direct.c         | 11 +++++++++++
>  3 files changed, 35 insertions(+)
> 
> diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
> index e133ccd60228..acfe3d0f78d1 100644
> --- a/Documentation/DMA-API.txt
> +++ b/Documentation/DMA-API.txt
> @@ -195,6 +195,14 @@ Requesting the required mask does not alter the current mask.  If you
>  wish to take advantage of it, you should issue a dma_set_mask()
>  call to set the mask to the value returned.
>  
> +::
> +
> +	size_t
> +	dma_direct_max_mapping_size(struct device *dev);
> +
> +Returns the maximum size of a mapping for the device. The size parameter
> +of the mapping functions like dma_map_single(), dma_map_page() and
> +others should not be larger than the returned value.
>  
>  Part Id - Streaming DMA mappings
>  --------------------------------
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index f6ded992c183..a3ca8a71a704 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -130,6 +130,7 @@ struct dma_map_ops {
>  			enum dma_data_direction direction);
>  	int (*dma_supported)(struct device *dev, u64 mask);
>  	u64 (*get_required_mask)(struct device *dev);
> +	size_t (*max_mapping_size)(struct device *dev);
>  };
>  
>  #define DMA_MAPPING_ERROR		(~(dma_addr_t)0)
> @@ -257,6 +258,8 @@ static inline void dma_direct_sync_sg_for_cpu(struct device *dev,
>  }
>  #endif
>  
> +size_t dma_direct_max_mapping_size(struct device *dev);
> +
>  #ifdef CONFIG_HAS_DMA
>  #include <asm/dma-mapping.h>
>  
> @@ -440,6 +443,19 @@ static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
>  	return 0;
>  }
>  
> +static inline size_t dma_max_mapping_size(struct device *dev)
> +{
> +	const struct dma_map_ops *ops = get_dma_ops(dev);
> +	size_t size = SIZE_MAX;
> +
> +	if (dma_is_direct(ops))
> +		size = dma_direct_max_mapping_size(dev);
> +	else if (ops && ops->max_mapping_size)
> +		size = ops->max_mapping_size(dev);
> +
> +	return size;
> +}
> +
>  void *dma_alloc_attrs(struct device *dev, size_t size, dma_addr_t *dma_handle,
>  		gfp_t flag, unsigned long attrs);
>  void dma_free_attrs(struct device *dev, size_t size, void *cpu_addr,
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 355d16acee6d..6310ad01f915 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -380,3 +380,14 @@ int dma_direct_supported(struct device *dev, u64 mask)
>  	 */
>  	return mask >= __phys_to_dma(dev, min_mask);
>  }
> +
> +size_t dma_direct_max_mapping_size(struct device *dev)
> +{
> +	size_t size = SIZE_MAX;
> +
> +	/* If SWIOTLB is active, use its maximum mapping size */
> +	if (is_swiotlb_active())
> +		size = swiotlb_max_mapping_size(dev);
> +
> +	return size;
> +}

When I build with these patches and with the virtio devices as modules I
get a build failure. Looks like this needs an EXPORT_SYMBOL() (I'm
assuming EXPORT_SYMBOL for DMA functions and not EXPORT_SYMBOL_GPL?).

Thanks,
Tom

> 

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 4/5] virtio: Introduce virtio_max_dma_size()
  2019-01-29  8:43 ` Joerg Roedel
@ 2019-01-30 15:10     ` Lendacky, Thomas
  2019-01-29 17:13   ` Christoph Hellwig
                       ` (2 subsequent siblings)
  3 siblings, 0 replies; 47+ messages in thread
From: Lendacky, Thomas @ 2019-01-30 15:10 UTC (permalink / raw)
  To: Joerg Roedel, Michael S . Tsirkin, Jason Wang,
	Konrad Rzeszutek Wilk, Christoph Hellwig
  Cc: Jens Axboe, virtualization, linux-block, linux-kernel, iommu,
	jfehlig, Grimm, Jon, Singh, Brijesh, jroedel

On 1/29/19 2:43 AM, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> This function returns the maximum segment size for a single
> dma transaction of a virtio device. The possible limit comes
> from the SWIOTLB implementation in the Linux kernel, that
> has an upper limit of (currently) 256kb of contiguous
> memory it can map. Other DMA-API implementations might also
> have limits.
> 
> Use the new dma_max_mapping_size() function to determine the
> maximum mapping size when DMA-API is in use for virtio.
> 
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
> ---
>  drivers/virtio/virtio_ring.c | 10 ++++++++++
>  include/linux/virtio.h       |  2 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index cd7e755484e3..9ca3fe6af9fa 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -266,6 +266,16 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
>  	return false;
>  }
>  
> +size_t virtio_max_dma_size(struct virtio_device *vdev)
> +{
> +	size_t max_segment_size = SIZE_MAX;
> +
> +	if (vring_use_dma_api(vdev))
> +		max_segment_size = dma_max_mapping_size(&vdev->dev);
> +
> +	return max_segment_size;
> +}

When I build with these patches and with the virtio devices as modules I
get a build failure. Looks like this needs an EXPORT_SYMBOL_GPL().

Thanks,
Tom

> +
>  static void *vring_alloc_queue(struct virtio_device *vdev, size_t size,
>  			      dma_addr_t *dma_handle, gfp_t flag)
>  {
> diff --git a/include/linux/virtio.h b/include/linux/virtio.h
> index fa1b5da2804e..673fe3ef3607 100644
> --- a/include/linux/virtio.h
> +++ b/include/linux/virtio.h
> @@ -157,6 +157,8 @@ int virtio_device_freeze(struct virtio_device *dev);
>  int virtio_device_restore(struct virtio_device *dev);
>  #endif
>  
> +size_t virtio_max_dma_size(struct virtio_device *vdev);
> +
>  #define virtio_device_for_each_vq(vdev, vq) \
>  	list_for_each_entry(vq, &vdev->vqs, list)
>  
> 

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 4/5] virtio: Introduce virtio_max_dma_size()
@ 2019-01-30 15:10     ` Lendacky, Thomas
  0 siblings, 0 replies; 47+ messages in thread
From: Lendacky, Thomas @ 2019-01-30 15:10 UTC (permalink / raw)
  To: Joerg Roedel, Michael S . Tsirkin, Jason Wang,
	Konrad Rzeszutek Wilk, Christoph Hellwig
  Cc: Jens Axboe, virtualization, linux-block, linux-kernel, iommu,
	jfehlig, Grimm, Jon, Singh, Brijesh, jroedel

On 1/29/19 2:43 AM, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> This function returns the maximum segment size for a single
> dma transaction of a virtio device. The possible limit comes
> from the SWIOTLB implementation in the Linux kernel, that
> has an upper limit of (currently) 256kb of contiguous
> memory it can map. Other DMA-API implementations might also
> have limits.
> 
> Use the new dma_max_mapping_size() function to determine the
> maximum mapping size when DMA-API is in use for virtio.
> 
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
> ---
>  drivers/virtio/virtio_ring.c | 10 ++++++++++
>  include/linux/virtio.h       |  2 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index cd7e755484e3..9ca3fe6af9fa 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -266,6 +266,16 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
>  	return false;
>  }
>  
> +size_t virtio_max_dma_size(struct virtio_device *vdev)
> +{
> +	size_t max_segment_size = SIZE_MAX;
> +
> +	if (vring_use_dma_api(vdev))
> +		max_segment_size = dma_max_mapping_size(&vdev->dev);
> +
> +	return max_segment_size;
> +}

When I build with these patches and with the virtio devices as modules I
get a build failure. Looks like this needs an EXPORT_SYMBOL_GPL().

Thanks,
Tom

> +
>  static void *vring_alloc_queue(struct virtio_device *vdev, size_t size,
>  			      dma_addr_t *dma_handle, gfp_t flag)
>  {
> diff --git a/include/linux/virtio.h b/include/linux/virtio.h
> index fa1b5da2804e..673fe3ef3607 100644
> --- a/include/linux/virtio.h
> +++ b/include/linux/virtio.h
> @@ -157,6 +157,8 @@ int virtio_device_freeze(struct virtio_device *dev);
>  int virtio_device_restore(struct virtio_device *dev);
>  #endif
>  
> +size_t virtio_max_dma_size(struct virtio_device *vdev);
> +
>  #define virtio_device_for_each_vq(vdev, vq) \
>  	list_for_each_entry(vq, &vdev->vqs, list)
>  
> 

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 4/5] virtio: Introduce virtio_max_dma_size()
  2019-01-29  8:43 ` Joerg Roedel
  2019-01-29 17:13   ` Christoph Hellwig
  2019-01-29 17:13   ` Christoph Hellwig
@ 2019-01-30 15:10   ` Lendacky, Thomas
  2019-01-30 15:10     ` Lendacky, Thomas
  3 siblings, 0 replies; 47+ messages in thread
From: Lendacky, Thomas @ 2019-01-30 15:10 UTC (permalink / raw)
  To: Joerg Roedel, Michael S . Tsirkin, Jason Wang,
	Konrad Rzeszutek Wilk, Christoph Hellwig
  Cc: Jens Axboe, jroedel, Singh, Brijesh, Grimm, Jon, jfehlig,
	linux-kernel, linux-block, iommu, virtualization

On 1/29/19 2:43 AM, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> This function returns the maximum segment size for a single
> dma transaction of a virtio device. The possible limit comes
> from the SWIOTLB implementation in the Linux kernel, that
> has an upper limit of (currently) 256kb of contiguous
> memory it can map. Other DMA-API implementations might also
> have limits.
> 
> Use the new dma_max_mapping_size() function to determine the
> maximum mapping size when DMA-API is in use for virtio.
> 
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
> ---
>  drivers/virtio/virtio_ring.c | 10 ++++++++++
>  include/linux/virtio.h       |  2 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index cd7e755484e3..9ca3fe6af9fa 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -266,6 +266,16 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
>  	return false;
>  }
>  
> +size_t virtio_max_dma_size(struct virtio_device *vdev)
> +{
> +	size_t max_segment_size = SIZE_MAX;
> +
> +	if (vring_use_dma_api(vdev))
> +		max_segment_size = dma_max_mapping_size(&vdev->dev);
> +
> +	return max_segment_size;
> +}

When I build with these patches and with the virtio devices as modules I
get a build failure. Looks like this needs an EXPORT_SYMBOL_GPL().

Thanks,
Tom

> +
>  static void *vring_alloc_queue(struct virtio_device *vdev, size_t size,
>  			      dma_addr_t *dma_handle, gfp_t flag)
>  {
> diff --git a/include/linux/virtio.h b/include/linux/virtio.h
> index fa1b5da2804e..673fe3ef3607 100644
> --- a/include/linux/virtio.h
> +++ b/include/linux/virtio.h
> @@ -157,6 +157,8 @@ int virtio_device_freeze(struct virtio_device *dev);
>  int virtio_device_restore(struct virtio_device *dev);
>  #endif
>  
> +size_t virtio_max_dma_size(struct virtio_device *vdev);
> +
>  #define virtio_device_for_each_vq(vdev, vq) \
>  	list_for_each_entry(vq, &vdev->vqs, list)
>  
> 

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 4/5] virtio: Introduce virtio_max_dma_size()
  2019-01-30 15:10     ` Lendacky, Thomas
@ 2019-01-30 15:49       ` Joerg Roedel
  -1 siblings, 0 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-30 15:49 UTC (permalink / raw)
  To: Lendacky, Thomas
  Cc: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig, Jens Axboe, virtualization, linux-block,
	linux-kernel, iommu, jfehlig, Grimm, Jon, Singh, Brijesh,
	jroedel

Hi Tom,

On Wed, Jan 30, 2019 at 03:10:29PM +0000, Lendacky, Thomas wrote:
> On 1/29/19 2:43 AM, Joerg Roedel wrote:

> > +size_t virtio_max_dma_size(struct virtio_device *vdev)
> > +{
> > +	size_t max_segment_size = SIZE_MAX;
> > +
> > +	if (vring_use_dma_api(vdev))
> > +		max_segment_size = dma_max_mapping_size(&vdev->dev);
> > +
> > +	return max_segment_size;
> > +}
> 
> When I build with these patches and with the virtio devices as modules I
> get a build failure. Looks like this needs an EXPORT_SYMBOL_GPL().

Thanks for pointing that out, I added the missing EXPORTs and will send
a new version shortly.

Regards,

	Joerg

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 4/5] virtio: Introduce virtio_max_dma_size()
@ 2019-01-30 15:49       ` Joerg Roedel
  0 siblings, 0 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-30 15:49 UTC (permalink / raw)
  To: Lendacky, Thomas
  Cc: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig, Jens Axboe, virtualization, linux-block,
	linux-kernel, iommu, jfehlig, Grimm, Jon, Singh, Brijesh,
	jroedel

Hi Tom,

On Wed, Jan 30, 2019 at 03:10:29PM +0000, Lendacky, Thomas wrote:
> On 1/29/19 2:43 AM, Joerg Roedel wrote:

> > +size_t virtio_max_dma_size(struct virtio_device *vdev)
> > +{
> > +	size_t max_segment_size = SIZE_MAX;
> > +
> > +	if (vring_use_dma_api(vdev))
> > +		max_segment_size = dma_max_mapping_size(&vdev->dev);
> > +
> > +	return max_segment_size;
> > +}
> 
> When I build with these patches and with the virtio devices as modules I
> get a build failure. Looks like this needs an EXPORT_SYMBOL_GPL().

Thanks for pointing that out, I added the missing EXPORTs and will send
a new version shortly.

Regards,

	Joerg

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 4/5] virtio: Introduce virtio_max_dma_size()
  2019-01-30 15:10     ` Lendacky, Thomas
  (?)
@ 2019-01-30 15:49     ` Joerg Roedel
  -1 siblings, 0 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-30 15:49 UTC (permalink / raw)
  To: Lendacky, Thomas
  Cc: Jens Axboe, Grimm, Jon, Singh, Brijesh, Konrad Rzeszutek Wilk,
	Michael S . Tsirkin, jfehlig, linux-kernel, virtualization,
	linux-block, iommu, jroedel, Christoph Hellwig

Hi Tom,

On Wed, Jan 30, 2019 at 03:10:29PM +0000, Lendacky, Thomas wrote:
> On 1/29/19 2:43 AM, Joerg Roedel wrote:

> > +size_t virtio_max_dma_size(struct virtio_device *vdev)
> > +{
> > +	size_t max_segment_size = SIZE_MAX;
> > +
> > +	if (vring_use_dma_api(vdev))
> > +		max_segment_size = dma_max_mapping_size(&vdev->dev);
> > +
> > +	return max_segment_size;
> > +}
> 
> When I build with these patches and with the virtio devices as modules I
> get a build failure. Looks like this needs an EXPORT_SYMBOL_GPL().

Thanks for pointing that out, I added the missing EXPORTs and will send
a new version shortly.

Regards,

	Joerg

^ permalink raw reply	[flat|nested] 47+ messages in thread

* [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-31 16:33 [PATCH 0/5 v6] Fix virtio-blk issue with SWIOTLB Joerg Roedel
  2019-01-31 16:34 ` [PATCH 2/5] swiotlb: Add is_swiotlb_active() function Joerg Roedel
@ 2019-01-31 16:34 ` Joerg Roedel
  1 sibling, 0 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-31 16:34 UTC (permalink / raw)
  To: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig
  Cc: Jens Axboe, virtualization, linux-block, linux-kernel, iommu,
	jfehlig, jon.grimm, brijesh.singh, joro, jroedel,
	Thomas.Lendacky

From: Joerg Roedel <jroedel@suse.de>

This function will be used from dma_direct code to determine
the maximum segment size of a dma mapping.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 include/linux/swiotlb.h | 6 ++++++
 kernel/dma/swiotlb.c    | 9 +++++++++
 2 files changed, 15 insertions(+)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 1c22d96e1742..e9e786b4b598 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -63,6 +63,7 @@ extern void swiotlb_tbl_sync_single(struct device *hwdev,
 extern int
 swiotlb_dma_supported(struct device *hwdev, u64 mask);
 size_t swiotlb_max_mapping_size(struct device *dev);
+bool is_swiotlb_active(void);
 
 #ifdef CONFIG_SWIOTLB
 extern enum swiotlb_force swiotlb_force;
@@ -100,6 +101,11 @@ static inline size_t swiotlb_max_mapping_size(struct device *dev)
 {
 	return SIZE_MAX;
 }
+
+static inline bool is_swiotlb_active(void)
+{
+	return false;
+}
 #endif /* CONFIG_SWIOTLB */
 
 extern void swiotlb_print_info(void);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 9cb21259cb0b..c873f9cc2146 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -667,3 +667,12 @@ size_t swiotlb_max_mapping_size(struct device *dev)
 {
 	return ((size_t)1 << IO_TLB_SHIFT) * IO_TLB_SEGSIZE;
 }
+
+bool is_swiotlb_active(void)
+{
+	/*
+	 * When SWIOTLB is initialized, even if io_tlb_start points to physical
+	 * address zero, io_tlb_end surely doesn't.
+	 */
+	return io_tlb_end != 0;
+}
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-31 16:33 [PATCH 0/5 v6] Fix virtio-blk issue with SWIOTLB Joerg Roedel
@ 2019-01-31 16:34 ` Joerg Roedel
  2019-01-31 16:34 ` Joerg Roedel
  1 sibling, 0 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-31 16:34 UTC (permalink / raw)
  To: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig
  Cc: Jens Axboe, Thomas.Lendacky, jroedel, brijesh.singh, joro,
	jon.grimm, jfehlig, linux-kernel, linux-block, iommu,
	virtualization

From: Joerg Roedel <jroedel@suse.de>

This function will be used from dma_direct code to determine
the maximum segment size of a dma mapping.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 include/linux/swiotlb.h | 6 ++++++
 kernel/dma/swiotlb.c    | 9 +++++++++
 2 files changed, 15 insertions(+)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 1c22d96e1742..e9e786b4b598 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -63,6 +63,7 @@ extern void swiotlb_tbl_sync_single(struct device *hwdev,
 extern int
 swiotlb_dma_supported(struct device *hwdev, u64 mask);
 size_t swiotlb_max_mapping_size(struct device *dev);
+bool is_swiotlb_active(void);
 
 #ifdef CONFIG_SWIOTLB
 extern enum swiotlb_force swiotlb_force;
@@ -100,6 +101,11 @@ static inline size_t swiotlb_max_mapping_size(struct device *dev)
 {
 	return SIZE_MAX;
 }
+
+static inline bool is_swiotlb_active(void)
+{
+	return false;
+}
 #endif /* CONFIG_SWIOTLB */
 
 extern void swiotlb_print_info(void);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 9cb21259cb0b..c873f9cc2146 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -667,3 +667,12 @@ size_t swiotlb_max_mapping_size(struct device *dev)
 {
 	return ((size_t)1 << IO_TLB_SHIFT) * IO_TLB_SEGSIZE;
 }
+
+bool is_swiotlb_active(void)
+{
+	/*
+	 * When SWIOTLB is initialized, even if io_tlb_start points to physical
+	 * address zero, io_tlb_end surely doesn't.
+	 */
+	return io_tlb_end != 0;
+}
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-30 16:40 [PATCH 0/5 v5] Fix virtio-blk issue with SWIOTLB Joerg Roedel
@ 2019-01-30 16:40 ` Joerg Roedel
  2019-01-30 16:40 ` Joerg Roedel
  1 sibling, 0 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-30 16:40 UTC (permalink / raw)
  To: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig
  Cc: Jens Axboe, virtualization, linux-block, linux-kernel, iommu,
	jfehlig, jon.grimm, brijesh.singh, joro, jroedel,
	Thomas.Lendacky

From: Joerg Roedel <jroedel@suse.de>

This function will be used from dma_direct code to determine
the maximum segment size of a dma mapping.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 include/linux/swiotlb.h | 6 ++++++
 kernel/dma/swiotlb.c    | 9 +++++++++
 2 files changed, 15 insertions(+)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 1c22d96e1742..e9e786b4b598 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -63,6 +63,7 @@ extern void swiotlb_tbl_sync_single(struct device *hwdev,
 extern int
 swiotlb_dma_supported(struct device *hwdev, u64 mask);
 size_t swiotlb_max_mapping_size(struct device *dev);
+bool is_swiotlb_active(void);
 
 #ifdef CONFIG_SWIOTLB
 extern enum swiotlb_force swiotlb_force;
@@ -100,6 +101,11 @@ static inline size_t swiotlb_max_mapping_size(struct device *dev)
 {
 	return SIZE_MAX;
 }
+
+static inline bool is_swiotlb_active(void)
+{
+	return false;
+}
 #endif /* CONFIG_SWIOTLB */
 
 extern void swiotlb_print_info(void);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 9cb21259cb0b..c873f9cc2146 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -667,3 +667,12 @@ size_t swiotlb_max_mapping_size(struct device *dev)
 {
 	return ((size_t)1 << IO_TLB_SHIFT) * IO_TLB_SEGSIZE;
 }
+
+bool is_swiotlb_active(void)
+{
+	/*
+	 * When SWIOTLB is initialized, even if io_tlb_start points to physical
+	 * address zero, io_tlb_end surely doesn't.
+	 */
+	return io_tlb_end != 0;
+}
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-30 16:40 [PATCH 0/5 v5] Fix virtio-blk issue with SWIOTLB Joerg Roedel
  2019-01-30 16:40 ` [PATCH 2/5] swiotlb: Add is_swiotlb_active() function Joerg Roedel
@ 2019-01-30 16:40 ` Joerg Roedel
  1 sibling, 0 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-30 16:40 UTC (permalink / raw)
  To: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig
  Cc: Jens Axboe, Thomas.Lendacky, jroedel, brijesh.singh, joro,
	jon.grimm, jfehlig, linux-kernel, linux-block, iommu,
	virtualization

From: Joerg Roedel <jroedel@suse.de>

This function will be used from dma_direct code to determine
the maximum segment size of a dma mapping.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 include/linux/swiotlb.h | 6 ++++++
 kernel/dma/swiotlb.c    | 9 +++++++++
 2 files changed, 15 insertions(+)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 1c22d96e1742..e9e786b4b598 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -63,6 +63,7 @@ extern void swiotlb_tbl_sync_single(struct device *hwdev,
 extern int
 swiotlb_dma_supported(struct device *hwdev, u64 mask);
 size_t swiotlb_max_mapping_size(struct device *dev);
+bool is_swiotlb_active(void);
 
 #ifdef CONFIG_SWIOTLB
 extern enum swiotlb_force swiotlb_force;
@@ -100,6 +101,11 @@ static inline size_t swiotlb_max_mapping_size(struct device *dev)
 {
 	return SIZE_MAX;
 }
+
+static inline bool is_swiotlb_active(void)
+{
+	return false;
+}
 #endif /* CONFIG_SWIOTLB */
 
 extern void swiotlb_print_info(void);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 9cb21259cb0b..c873f9cc2146 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -667,3 +667,12 @@ size_t swiotlb_max_mapping_size(struct device *dev)
 {
 	return ((size_t)1 << IO_TLB_SHIFT) * IO_TLB_SEGSIZE;
 }
+
+bool is_swiotlb_active(void)
+{
+	/*
+	 * When SWIOTLB is initialized, even if io_tlb_start points to physical
+	 * address zero, io_tlb_end surely doesn't.
+	 */
+	return io_tlb_end != 0;
+}
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 47+ messages in thread

* Re: [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-24 15:00         ` Joerg Roedel
@ 2019-01-28 17:19           ` Michael S. Tsirkin
  2019-01-28 17:19           ` Michael S. Tsirkin
  1 sibling, 0 replies; 47+ messages in thread
From: Michael S. Tsirkin @ 2019-01-28 17:19 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Christoph Hellwig, Jason Wang, Konrad Rzeszutek Wilk, Jens Axboe,
	virtualization, linux-block, linux-kernel, iommu, jfehlig,
	jon.grimm, brijesh.singh, jroedel

On Thu, Jan 24, 2019 at 04:00:00PM +0100, Joerg Roedel wrote:
> On Thu, Jan 24, 2019 at 09:41:07AM +0100, Christoph Hellwig wrote:
> > On Thu, Jan 24, 2019 at 09:29:23AM +0100, Joerg Roedel wrote:
> > > > As I've just introduced and fixed a bug in this area in the current
> > > > cycle - I don't think no_iotlb_memory is what your want (and maybe
> > > > not useful at all): if the arch valls swiotlb_exit after previously
> > > > initializing a buffer it won't be set.  You probably want to check
> > > > for non-zero io_tlb_start and/or io_tlb_end.
> > > 
> > > Okay, but that requires that I also set io_tlb_start and friends back to
> > > zero in the failure path of swiotlb_init(). Otherwise it could be left
> > > non-zero in case swiotlb_init_with_tbl() returns an error.
> > 
> > Indeed, and we'll need to do that anyway as otherwise the dma mapping
> > path might cause problems similar to the one when swiotlb_exit is
> > called that I fixed.
> 
> Turns out the the error path in swiotlb_init() is redundant because it
> will never be executed. If the function returns it will always return 0
> because in case of failure it will just panic (through memblock_alloc).
> 
> I'll clean that up in a separate patch-set. There are more users of that
> function and all of them panic when the function fails.
> 
> 
> 	Joerg

OK so are you going to post a new version then? Time's running out for 5.0.
This isn't a regression so maybe we should just defer it all to 5.1.

-- 
MST

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-24 15:00         ` Joerg Roedel
  2019-01-28 17:19           ` Michael S. Tsirkin
@ 2019-01-28 17:19           ` Michael S. Tsirkin
  1 sibling, 0 replies; 47+ messages in thread
From: Michael S. Tsirkin @ 2019-01-28 17:19 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Jens Axboe, jroedel, brijesh.singh, Konrad Rzeszutek Wilk,
	jon.grimm, jfehlig, linux-kernel, virtualization, linux-block,
	iommu, Christoph Hellwig

On Thu, Jan 24, 2019 at 04:00:00PM +0100, Joerg Roedel wrote:
> On Thu, Jan 24, 2019 at 09:41:07AM +0100, Christoph Hellwig wrote:
> > On Thu, Jan 24, 2019 at 09:29:23AM +0100, Joerg Roedel wrote:
> > > > As I've just introduced and fixed a bug in this area in the current
> > > > cycle - I don't think no_iotlb_memory is what your want (and maybe
> > > > not useful at all): if the arch valls swiotlb_exit after previously
> > > > initializing a buffer it won't be set.  You probably want to check
> > > > for non-zero io_tlb_start and/or io_tlb_end.
> > > 
> > > Okay, but that requires that I also set io_tlb_start and friends back to
> > > zero in the failure path of swiotlb_init(). Otherwise it could be left
> > > non-zero in case swiotlb_init_with_tbl() returns an error.
> > 
> > Indeed, and we'll need to do that anyway as otherwise the dma mapping
> > path might cause problems similar to the one when swiotlb_exit is
> > called that I fixed.
> 
> Turns out the the error path in swiotlb_init() is redundant because it
> will never be executed. If the function returns it will always return 0
> because in case of failure it will just panic (through memblock_alloc).
> 
> I'll clean that up in a separate patch-set. There are more users of that
> function and all of them panic when the function fails.
> 
> 
> 	Joerg

OK so are you going to post a new version then? Time's running out for 5.0.
This isn't a regression so maybe we should just defer it all to 5.1.

-- 
MST

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-24  8:41         ` Christoph Hellwig
  (?)
@ 2019-01-24 15:00         ` Joerg Roedel
  2019-01-28 17:19           ` Michael S. Tsirkin
  2019-01-28 17:19           ` Michael S. Tsirkin
  -1 siblings, 2 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-24 15:00 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Jens Axboe, virtualization, linux-block, linux-kernel, iommu,
	jfehlig, jon.grimm, brijesh.singh, jroedel

On Thu, Jan 24, 2019 at 09:41:07AM +0100, Christoph Hellwig wrote:
> On Thu, Jan 24, 2019 at 09:29:23AM +0100, Joerg Roedel wrote:
> > > As I've just introduced and fixed a bug in this area in the current
> > > cycle - I don't think no_iotlb_memory is what your want (and maybe
> > > not useful at all): if the arch valls swiotlb_exit after previously
> > > initializing a buffer it won't be set.  You probably want to check
> > > for non-zero io_tlb_start and/or io_tlb_end.
> > 
> > Okay, but that requires that I also set io_tlb_start and friends back to
> > zero in the failure path of swiotlb_init(). Otherwise it could be left
> > non-zero in case swiotlb_init_with_tbl() returns an error.
> 
> Indeed, and we'll need to do that anyway as otherwise the dma mapping
> path might cause problems similar to the one when swiotlb_exit is
> called that I fixed.

Turns out the the error path in swiotlb_init() is redundant because it
will never be executed. If the function returns it will always return 0
because in case of failure it will just panic (through memblock_alloc).

I'll clean that up in a separate patch-set. There are more users of that
function and all of them panic when the function fails.


	Joerg

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-24  8:41         ` Christoph Hellwig
  (?)
  (?)
@ 2019-01-24 15:00         ` Joerg Roedel
  -1 siblings, 0 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-24 15:00 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Jens Axboe, jon.grimm, brijesh.singh, Konrad Rzeszutek Wilk,
	Michael S . Tsirkin, jfehlig, linux-kernel, virtualization,
	linux-block, iommu, jroedel

On Thu, Jan 24, 2019 at 09:41:07AM +0100, Christoph Hellwig wrote:
> On Thu, Jan 24, 2019 at 09:29:23AM +0100, Joerg Roedel wrote:
> > > As I've just introduced and fixed a bug in this area in the current
> > > cycle - I don't think no_iotlb_memory is what your want (and maybe
> > > not useful at all): if the arch valls swiotlb_exit after previously
> > > initializing a buffer it won't be set.  You probably want to check
> > > for non-zero io_tlb_start and/or io_tlb_end.
> > 
> > Okay, but that requires that I also set io_tlb_start and friends back to
> > zero in the failure path of swiotlb_init(). Otherwise it could be left
> > non-zero in case swiotlb_init_with_tbl() returns an error.
> 
> Indeed, and we'll need to do that anyway as otherwise the dma mapping
> path might cause problems similar to the one when swiotlb_exit is
> called that I fixed.

Turns out the the error path in swiotlb_init() is redundant because it
will never be executed. If the function returns it will always return 0
because in case of failure it will just panic (through memblock_alloc).

I'll clean that up in a separate patch-set. There are more users of that
function and all of them panic when the function fails.


	Joerg

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
@ 2019-01-24  8:41         ` Christoph Hellwig
  0 siblings, 0 replies; 47+ messages in thread
From: Christoph Hellwig @ 2019-01-24  8:41 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Christoph Hellwig, Michael S . Tsirkin, Jason Wang,
	Konrad Rzeszutek Wilk, Jens Axboe, virtualization, linux-block,
	linux-kernel, iommu, jfehlig, jon.grimm, brijesh.singh, jroedel

On Thu, Jan 24, 2019 at 09:29:23AM +0100, Joerg Roedel wrote:
> > As I've just introduced and fixed a bug in this area in the current
> > cycle - I don't think no_iotlb_memory is what your want (and maybe
> > not useful at all): if the arch valls swiotlb_exit after previously
> > initializing a buffer it won't be set.  You probably want to check
> > for non-zero io_tlb_start and/or io_tlb_end.
> 
> Okay, but that requires that I also set io_tlb_start and friends back to
> zero in the failure path of swiotlb_init(). Otherwise it could be left
> non-zero in case swiotlb_init_with_tbl() returns an error.

Indeed, and we'll need to do that anyway as otherwise the dma mapping
path might cause problems similar to the one when swiotlb_exit is
called that I fixed.

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
@ 2019-01-24  8:41         ` Christoph Hellwig
  0 siblings, 0 replies; 47+ messages in thread
From: Christoph Hellwig @ 2019-01-24  8:41 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Jens Axboe, jon.grimm-5C7GfCeVMHo, brijesh.singh-5C7GfCeVMHo,
	Konrad Rzeszutek Wilk, Jason Wang, Michael S . Tsirkin,
	jfehlig-IBi9RG/b67k, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	linux-block-u79uwXL29TY76Z2rM5mHXA,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	jroedel-l3A5Bk7waGM, Christoph Hellwig

On Thu, Jan 24, 2019 at 09:29:23AM +0100, Joerg Roedel wrote:
> > As I've just introduced and fixed a bug in this area in the current
> > cycle - I don't think no_iotlb_memory is what your want (and maybe
> > not useful at all): if the arch valls swiotlb_exit after previously
> > initializing a buffer it won't be set.  You probably want to check
> > for non-zero io_tlb_start and/or io_tlb_end.
> 
> Okay, but that requires that I also set io_tlb_start and friends back to
> zero in the failure path of swiotlb_init(). Otherwise it could be left
> non-zero in case swiotlb_init_with_tbl() returns an error.

Indeed, and we'll need to do that anyway as otherwise the dma mapping
path might cause problems similar to the one when swiotlb_exit is
called that I fixed.

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-24  8:29     ` Joerg Roedel
@ 2019-01-24  8:41       ` Christoph Hellwig
  2019-01-24  8:41         ` Christoph Hellwig
  1 sibling, 0 replies; 47+ messages in thread
From: Christoph Hellwig @ 2019-01-24  8:41 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Jens Axboe, jon.grimm, brijesh.singh, Konrad Rzeszutek Wilk,
	Michael S . Tsirkin, jfehlig, linux-kernel, virtualization,
	linux-block, iommu, jroedel, Christoph Hellwig

On Thu, Jan 24, 2019 at 09:29:23AM +0100, Joerg Roedel wrote:
> > As I've just introduced and fixed a bug in this area in the current
> > cycle - I don't think no_iotlb_memory is what your want (and maybe
> > not useful at all): if the arch valls swiotlb_exit after previously
> > initializing a buffer it won't be set.  You probably want to check
> > for non-zero io_tlb_start and/or io_tlb_end.
> 
> Okay, but that requires that I also set io_tlb_start and friends back to
> zero in the failure path of swiotlb_init(). Otherwise it could be left
> non-zero in case swiotlb_init_with_tbl() returns an error.

Indeed, and we'll need to do that anyway as otherwise the dma mapping
path might cause problems similar to the one when swiotlb_exit is
called that I fixed.

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-23 21:27   ` Christoph Hellwig
  2019-01-24  8:29     ` Joerg Roedel
@ 2019-01-24  8:29     ` Joerg Roedel
  2019-01-24  8:41       ` Christoph Hellwig
  2019-01-24  8:41         ` Christoph Hellwig
  1 sibling, 2 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-24  8:29 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Jens Axboe, virtualization, linux-block, linux-kernel, iommu,
	jfehlig, jon.grimm, brijesh.singh, jroedel

On Wed, Jan 23, 2019 at 10:27:55PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 23, 2019 at 05:30:46PM +0100, Joerg Roedel wrote:
> > +bool is_swiotlb_active(void)
> > +{
> > +	return !no_iotlb_memory;
> > +}
> 
> As I've just introduced and fixed a bug in this area in the current
> cycle - I don't think no_iotlb_memory is what your want (and maybe
> not useful at all): if the arch valls swiotlb_exit after previously
> initializing a buffer it won't be set.  You probably want to check
> for non-zero io_tlb_start and/or io_tlb_end.

Okay, but that requires that I also set io_tlb_start and friends back to
zero in the failure path of swiotlb_init(). Otherwise it could be left
non-zero in case swiotlb_init_with_tbl() returns an error.


Regards,

	Joerg

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-23 21:27   ` Christoph Hellwig
@ 2019-01-24  8:29     ` Joerg Roedel
  2019-01-24  8:29     ` Joerg Roedel
  1 sibling, 0 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-24  8:29 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Jens Axboe, jon.grimm, brijesh.singh, Konrad Rzeszutek Wilk,
	Michael S . Tsirkin, jfehlig, linux-kernel, virtualization,
	linux-block, iommu, jroedel

On Wed, Jan 23, 2019 at 10:27:55PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 23, 2019 at 05:30:46PM +0100, Joerg Roedel wrote:
> > +bool is_swiotlb_active(void)
> > +{
> > +	return !no_iotlb_memory;
> > +}
> 
> As I've just introduced and fixed a bug in this area in the current
> cycle - I don't think no_iotlb_memory is what your want (and maybe
> not useful at all): if the arch valls swiotlb_exit after previously
> initializing a buffer it won't be set.  You probably want to check
> for non-zero io_tlb_start and/or io_tlb_end.

Okay, but that requires that I also set io_tlb_start and friends back to
zero in the failure path of swiotlb_init(). Otherwise it could be left
non-zero in case swiotlb_init_with_tbl() returns an error.


Regards,

	Joerg

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-23 16:30 ` [PATCH 2/5] swiotlb: Add is_swiotlb_active() function Joerg Roedel
  2019-01-23 21:27   ` Christoph Hellwig
@ 2019-01-23 21:27   ` Christoph Hellwig
  2019-01-24  8:29     ` Joerg Roedel
  2019-01-24  8:29     ` Joerg Roedel
  1 sibling, 2 replies; 47+ messages in thread
From: Christoph Hellwig @ 2019-01-23 21:27 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig, Jens Axboe, virtualization, linux-block,
	linux-kernel, iommu, jfehlig, jon.grimm, brijesh.singh, jroedel

On Wed, Jan 23, 2019 at 05:30:46PM +0100, Joerg Roedel wrote:
> +bool is_swiotlb_active(void)
> +{
> +	return !no_iotlb_memory;
> +}

As I've just introduced and fixed a bug in this area in the current
cycle - I don't think no_iotlb_memory is what your want (and maybe
not useful at all): if the arch valls swiotlb_exit after previously
initializing a buffer it won't be set.  You probably want to check
for non-zero io_tlb_start and/or io_tlb_end.

^ permalink raw reply	[flat|nested] 47+ messages in thread

* Re: [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-23 16:30 ` [PATCH 2/5] swiotlb: Add is_swiotlb_active() function Joerg Roedel
@ 2019-01-23 21:27   ` Christoph Hellwig
  2019-01-23 21:27   ` Christoph Hellwig
  1 sibling, 0 replies; 47+ messages in thread
From: Christoph Hellwig @ 2019-01-23 21:27 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Jens Axboe, jon.grimm, brijesh.singh, Konrad Rzeszutek Wilk,
	Michael S . Tsirkin, jfehlig, linux-kernel, virtualization,
	linux-block, iommu, jroedel, Christoph Hellwig

On Wed, Jan 23, 2019 at 05:30:46PM +0100, Joerg Roedel wrote:
> +bool is_swiotlb_active(void)
> +{
> +	return !no_iotlb_memory;
> +}

As I've just introduced and fixed a bug in this area in the current
cycle - I don't think no_iotlb_memory is what your want (and maybe
not useful at all): if the arch valls swiotlb_exit after previously
initializing a buffer it won't be set.  You probably want to check
for non-zero io_tlb_start and/or io_tlb_end.

^ permalink raw reply	[flat|nested] 47+ messages in thread

* [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-23 16:30 [PATCH 0/5 v3] Fix virtio-blk issue with SWIOTLB Joerg Roedel
@ 2019-01-23 16:30 ` Joerg Roedel
  2019-01-23 21:27   ` Christoph Hellwig
  2019-01-23 21:27   ` Christoph Hellwig
  2019-01-23 16:30 ` Joerg Roedel
  1 sibling, 2 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-23 16:30 UTC (permalink / raw)
  To: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig
  Cc: Jens Axboe, virtualization, linux-block, linux-kernel, iommu,
	jfehlig, jon.grimm, brijesh.singh, joro, jroedel

From: Joerg Roedel <jroedel@suse.de>

This function will be used from dma_direct code to determine
the maximum segment size of a dma mapping.

Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 include/linux/swiotlb.h | 6 ++++++
 kernel/dma/swiotlb.c    | 5 +++++
 2 files changed, 11 insertions(+)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index ceb623321f38..5c087d330b4b 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -63,6 +63,7 @@ extern void swiotlb_tbl_sync_single(struct device *hwdev,
 extern int
 swiotlb_dma_supported(struct device *hwdev, u64 mask);
 extern size_t swiotlb_max_mapping_size(struct device *dev);
+bool is_swiotlb_active(void);
 
 #ifdef CONFIG_SWIOTLB
 extern enum swiotlb_force swiotlb_force;
@@ -100,6 +101,11 @@ static inline size_t swiotlb_max_mapping_size(struct device *dev)
 {
 	return SIZE_MAX;
 }
+
+static inline bool is_swiotlb_active(void)
+{
+	return false;
+}
 #endif /* CONFIG_SWIOTLB */
 
 extern void swiotlb_print_info(void);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 9cb21259cb0b..9fbd075081d9 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -667,3 +667,8 @@ size_t swiotlb_max_mapping_size(struct device *dev)
 {
 	return ((size_t)1 << IO_TLB_SHIFT) * IO_TLB_SEGSIZE;
 }
+
+bool is_swiotlb_active(void)
+{
+	return !no_iotlb_memory;
+}
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 47+ messages in thread

* [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
  2019-01-23 16:30 [PATCH 0/5 v3] Fix virtio-blk issue with SWIOTLB Joerg Roedel
  2019-01-23 16:30 ` [PATCH 2/5] swiotlb: Add is_swiotlb_active() function Joerg Roedel
@ 2019-01-23 16:30 ` Joerg Roedel
  1 sibling, 0 replies; 47+ messages in thread
From: Joerg Roedel @ 2019-01-23 16:30 UTC (permalink / raw)
  To: Michael S . Tsirkin, Jason Wang, Konrad Rzeszutek Wilk,
	Christoph Hellwig
  Cc: Jens Axboe, jroedel, brijesh.singh, joro, jon.grimm, jfehlig,
	linux-kernel, linux-block, iommu, virtualization

From: Joerg Roedel <jroedel@suse.de>

This function will be used from dma_direct code to determine
the maximum segment size of a dma mapping.

Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 include/linux/swiotlb.h | 6 ++++++
 kernel/dma/swiotlb.c    | 5 +++++
 2 files changed, 11 insertions(+)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index ceb623321f38..5c087d330b4b 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -63,6 +63,7 @@ extern void swiotlb_tbl_sync_single(struct device *hwdev,
 extern int
 swiotlb_dma_supported(struct device *hwdev, u64 mask);
 extern size_t swiotlb_max_mapping_size(struct device *dev);
+bool is_swiotlb_active(void);
 
 #ifdef CONFIG_SWIOTLB
 extern enum swiotlb_force swiotlb_force;
@@ -100,6 +101,11 @@ static inline size_t swiotlb_max_mapping_size(struct device *dev)
 {
 	return SIZE_MAX;
 }
+
+static inline bool is_swiotlb_active(void)
+{
+	return false;
+}
 #endif /* CONFIG_SWIOTLB */
 
 extern void swiotlb_print_info(void);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 9cb21259cb0b..9fbd075081d9 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -667,3 +667,8 @@ size_t swiotlb_max_mapping_size(struct device *dev)
 {
 	return ((size_t)1 << IO_TLB_SHIFT) * IO_TLB_SEGSIZE;
 }
+
+bool is_swiotlb_active(void)
+{
+	return !no_iotlb_memory;
+}
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 47+ messages in thread

end of thread, other threads:[~2019-01-31 16:34 UTC | newest]

Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-29  8:43 [PATCH 0/5 v4] Fix virtio-blk issue with SWIOTLB Joerg Roedel
2019-01-29  8:43 ` [PATCH 1/5] swiotlb: Introduce swiotlb_max_mapping_size() Joerg Roedel
2019-01-29  8:43 ` Joerg Roedel
2019-01-29 17:12   ` Christoph Hellwig
2019-01-29 17:12   ` Christoph Hellwig
2019-01-29  8:43 ` [PATCH 2/5] swiotlb: Add is_swiotlb_active() function Joerg Roedel
2019-01-29  8:43 ` Joerg Roedel
2019-01-29 17:12   ` Christoph Hellwig
2019-01-29 17:12   ` Christoph Hellwig
2019-01-29  8:43 ` [PATCH 3/5] dma: Introduce dma_max_mapping_size() Joerg Roedel
2019-01-29  8:43 ` Joerg Roedel
2019-01-29 17:13   ` Christoph Hellwig
2019-01-29 17:13   ` Christoph Hellwig
2019-01-30 15:09   ` Lendacky, Thomas
2019-01-30 15:09   ` Lendacky, Thomas
2019-01-30 15:09     ` Lendacky, Thomas
2019-01-29  8:43 ` [PATCH 4/5] virtio: Introduce virtio_max_dma_size() Joerg Roedel
2019-01-29  8:43 ` Joerg Roedel
2019-01-29 17:13   ` Christoph Hellwig
2019-01-29 17:13   ` Christoph Hellwig
2019-01-30 15:10   ` Lendacky, Thomas
2019-01-30 15:10   ` Lendacky, Thomas
2019-01-30 15:10     ` Lendacky, Thomas
2019-01-30 15:49     ` Joerg Roedel
2019-01-30 15:49     ` Joerg Roedel
2019-01-30 15:49       ` Joerg Roedel
2019-01-29  8:43 ` [PATCH 5/5] virtio-blk: Consider virtio_max_dma_size() for maximum segment size Joerg Roedel
2019-01-29  8:43 ` Joerg Roedel
2019-01-29 17:13   ` Christoph Hellwig
2019-01-29 17:13   ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2019-01-31 16:33 [PATCH 0/5 v6] Fix virtio-blk issue with SWIOTLB Joerg Roedel
2019-01-31 16:34 ` [PATCH 2/5] swiotlb: Add is_swiotlb_active() function Joerg Roedel
2019-01-31 16:34 ` Joerg Roedel
2019-01-30 16:40 [PATCH 0/5 v5] Fix virtio-blk issue with SWIOTLB Joerg Roedel
2019-01-30 16:40 ` [PATCH 2/5] swiotlb: Add is_swiotlb_active() function Joerg Roedel
2019-01-30 16:40 ` Joerg Roedel
2019-01-23 16:30 [PATCH 0/5 v3] Fix virtio-blk issue with SWIOTLB Joerg Roedel
2019-01-23 16:30 ` [PATCH 2/5] swiotlb: Add is_swiotlb_active() function Joerg Roedel
2019-01-23 21:27   ` Christoph Hellwig
2019-01-23 21:27   ` Christoph Hellwig
2019-01-24  8:29     ` Joerg Roedel
2019-01-24  8:29     ` Joerg Roedel
2019-01-24  8:41       ` Christoph Hellwig
2019-01-24  8:41       ` Christoph Hellwig
2019-01-24  8:41         ` Christoph Hellwig
2019-01-24 15:00         ` Joerg Roedel
2019-01-28 17:19           ` Michael S. Tsirkin
2019-01-28 17:19           ` Michael S. Tsirkin
2019-01-24 15:00         ` Joerg Roedel
2019-01-23 16:30 ` Joerg Roedel

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.