Linux virtualization list
 help / color / mirror / Atom feed
* Re: [PATCH net-next V4 5/5] vhost: access vq metadata through kernel virtual address
From: Michael S. Tsirkin @ 2019-01-23 14:08 UTC (permalink / raw)
  To: Jason Wang; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20190123095557.30168-6-jasowang@redhat.com>

On Wed, Jan 23, 2019 at 05:55:57PM +0800, Jason Wang wrote:
> It was noticed that the copy_user() friends that was used to access
> virtqueue metdata tends to be very expensive for dataplane
> implementation like vhost since it involves lots of software checks,
> speculation barrier, hardware feature toggling (e.g SMAP). The
> extra cost will be more obvious when transferring small packets since
> the time spent on metadata accessing become more significant.
> 
> This patch tries to eliminate those overheads by accessing them
> through kernel virtual address by vmap(). To make the pages can be
> migrated, instead of pinning them through GUP, we use MMU notifiers to
> invalidate vmaps and re-establish vmaps during each round of metadata
> prefetching if necessary. For devices that doesn't use metadata
> prefetching, the memory accessors fallback to normal copy_user()
> implementation gracefully. The invalidation was synchronized with
> datapath through vq mutex, and in order to avoid hold vq mutex during
> range checking, MMU notifier was teared down when trying to modify vq
> metadata.
> 
> Another thing is kernel lacks efficient solution for tracking dirty
> pages by vmap(), this will lead issues if vhost is using file backed
> memory which needs care of writeback. This patch solves this issue by
> just skipping the vma that is file backed and fallback to normal
> copy_user() friends. This might introduce some overheads for file
> backed users but consider this use case is rare we could do
> optimizations on top.
> 
> Note that this was only done when device IOTLB is not enabled. We
> could use similar method to optimize it in the future.
> 
> Tests shows at most about 22% improvement on TX PPS when using
> virtio-user + vhost_net + xdp1 + TAP on 2.6GHz Broadwell:
> 
>         SMAP on | SMAP off
> Before: 5.0Mpps | 6.6Mpps
> After:  6.1Mpps | 7.4Mpps
> 
> Signed-off-by: Jason Wang <jasowang@redhat.com>


So this is the bulk of the change.
Threee things that I need to look into
- Are there any security issues with bypassing the speculation barrier
  that is normally present after access_ok?
- How hard does the special handling for
  file backed storage make testing?
  On the one hand we could add a module parameter to
  force copy to/from user. on the other that's
  another configuration we need to support.
  But iotlb is not using vmap, so maybe that's enough
  for testing.
- How hard is it to figure out which mode uses which code.



Meanwhile, could you pls post data comparing this last patch with the
below?  This removes the speculation barrier replacing it with a
(useless but at least more lightweight) data dependency.

Thanks!


diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index bac939af8dbb..352ee7e14476 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -739,7 +739,7 @@ static int vhost_copy_to_user(struct vhost_virtqueue *vq, void __user *to,
 	int ret;
 
 	if (!vq->iotlb)
-		return __copy_to_user(to, from, size);
+		return copy_to_user(to, from, size);
 	else {
 		/* This function should be called after iotlb
 		 * prefetch, which means we're sure that all vq
@@ -752,7 +752,7 @@ static int vhost_copy_to_user(struct vhost_virtqueue *vq, void __user *to,
 				     VHOST_ADDR_USED);
 
 		if (uaddr)
-			return __copy_to_user(uaddr, from, size);
+			return copy_to_user(uaddr, from, size);
 
 		ret = translate_desc(vq, (u64)(uintptr_t)to, size, vq->iotlb_iov,
 				     ARRAY_SIZE(vq->iotlb_iov),
@@ -774,7 +774,7 @@ static int vhost_copy_from_user(struct vhost_virtqueue *vq, void *to,
 	int ret;
 
 	if (!vq->iotlb)
-		return __copy_from_user(to, from, size);
+		return copy_from_user(to, from, size);
 	else {
 		/* This function should be called after iotlb
 		 * prefetch, which means we're sure that vq
@@ -787,7 +787,7 @@ static int vhost_copy_from_user(struct vhost_virtqueue *vq, void *to,
 		struct iov_iter f;
 
 		if (uaddr)
-			return __copy_from_user(to, uaddr, size);
+			return copy_from_user(to, uaddr, size);
 
 		ret = translate_desc(vq, (u64)(uintptr_t)from, size, vq->iotlb_iov,
 				     ARRAY_SIZE(vq->iotlb_iov),
@@ -855,13 +855,13 @@ static inline void __user *__vhost_get_user(struct vhost_virtqueue *vq,
 ({ \
 	int ret = -EFAULT; \
 	if (!vq->iotlb) { \
-		ret = __put_user(x, ptr); \
+		ret = put_user(x, ptr); \
 	} else { \
 		__typeof__(ptr) to = \
 			(__typeof__(ptr)) __vhost_get_user(vq, ptr,	\
 					  sizeof(*ptr), VHOST_ADDR_USED); \
 		if (to != NULL) \
-			ret = __put_user(x, to); \
+			ret = put_user(x, to); \
 		else \
 			ret = -EFAULT;	\
 	} \
@@ -872,14 +872,14 @@ static inline void __user *__vhost_get_user(struct vhost_virtqueue *vq,
 ({ \
 	int ret; \
 	if (!vq->iotlb) { \
-		ret = __get_user(x, ptr); \
+		ret = get_user(x, ptr); \
 	} else { \
 		__typeof__(ptr) from = \
 			(__typeof__(ptr)) __vhost_get_user(vq, ptr, \
 							   sizeof(*ptr), \
 							   type); \
 		if (from != NULL) \
-			ret = __get_user(x, from); \
+			ret = get_user(x, from); \
 		else \
 			ret = -EFAULT; \
 	} \

^ permalink raw reply related

* [PATCH 0/5 v3] Fix virtio-blk issue with SWIOTLB
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

Hi,

here is the third 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/

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.

Changes to v2 are:

	* Check if SWIOTLB is active before returning its limit in
	  dma_direct_max_mapping_size()

	* Only apply the maximum segment limit in virtio-blk when
	  DMA-API is used for the vring

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

 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         | 10 ++++++++++
 7 files changed, 66 insertions(+), 4 deletions(-)

-- 
2.17.1

^ permalink raw reply

* [PATCH 1/5] swiotlb: Introduce swiotlb_max_mapping_size()
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
In-Reply-To: <20190123163049.24863-1-joro@8bytes.org>

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.

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..ceb623321f38 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);
+extern 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

* [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
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
In-Reply-To: <20190123163049.24863-1-joro@8bytes.org>

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

* [PATCH 3/5] dma: Introduce dma_max_mapping_size()
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
In-Reply-To: <20190123163049.24863-1-joro@8bytes.org>

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.

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

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

* [PATCH 4/5] virtio: Introduce virtio_max_dma_size()
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
In-Reply-To: <20190123163049.24863-1-joro@8bytes.org>

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.

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

* [PATCH 5/5] virtio-blk: Consider virtio_max_dma_size() for maximum segment size
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
In-Reply-To: <20190123163049.24863-1-joro@8bytes.org>

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.

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

* Re: [PATCH] drm: Split out drm_probe_helper.h
From: Sam Ravnborg @ 2019-01-23 17:00 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Neil Armstrong, nouveau, Liviu Dudau, DRI Development,
	virtualization, Laurent Pinchart, Benjamin Gaignard,
	Daniel Vetter, linux-stm32, linux-samsung-soc,
	Oleksandr Andrushchenko, amd-gfx, linux-rockchip, CK Hu,
	spice-devel, Jani Nikula, linux-arm-msm, intel-gfx, etnaviv,
	Jani Nikula, linux-mediatek, Rodrigo Vivi, linux-tegra
In-Reply-To: <20190117210334.13234-1-daniel.vetter@ffwll.ch>

Hi Daniel.

On Thu, Jan 17, 2019 at 10:03:34PM +0100, Daniel Vetter wrote:
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
> 
> To make sure I actually achieved the goal here I went through all
> drivers. And indeed, all atomic drivers are now free of
> drm_crtc_helper.h includes.

How are the plans to get this patchset merged?
There were dependencies on onging drmP.h removal in i915 IIRC?
I guess my "Minimize drmP.h dependencies" patch-set also have a role in this.

This does not hold up any work of mine, mainly wanted to make
sure this was not lost between all the other patches.

	Sam

^ permalink raw reply

* Re: [PATCH 0/5 v3] Fix virtio-blk issue with SWIOTLB
From: Konrad Rzeszutek Wilk @ 2019-01-23 17:09 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Jens Axboe, jroedel, brijesh.singh, Michael S . Tsirkin,
	jon.grimm, jfehlig, linux-kernel, virtualization, linux-block,
	iommu, Christoph Hellwig
In-Reply-To: <20190123163049.24863-1-joro@8bytes.org>

On Wed, Jan 23, 2019 at 05:30:44PM +0100, Joerg Roedel wrote:
> Hi,
> 
> here is the third 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/
> 
> 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.
> 
> Changes to v2 are:
> 
> 	* Check if SWIOTLB is active before returning its limit in
> 	  dma_direct_max_mapping_size()
> 
> 	* Only apply the maximum segment limit in virtio-blk when
> 	  DMA-API is used for the vring
> 
> 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
> 
>  drivers/block/virtio_blk.c   | 10 ++++++----
>  drivers/virtio/virtio_ring.c | 10 ++++++++++

The kvm-devel mailing list should have been copied on those.

When you do can you please put 'Reviewed-by: Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com>' on all of them?

Thank you!

P.S.
Christopher, I am assuming you are OK with this idea, if so - and once
the owners of 'virtio' Ack, do you want to put it in my tree?

Thanks!
>  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         | 10 ++++++++++
>  7 files changed, 66 insertions(+), 4 deletions(-)


> 
> -- 
> 2.17.1
> 

^ permalink raw reply

* Re: [PATCH net-next V4 0/5] vhost: accelerate metadata access through vmap()
From: David Miller @ 2019-01-23 17:24 UTC (permalink / raw)
  To: mst; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20190123085652-mutt-send-email-mst@kernel.org>

From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Wed, 23 Jan 2019 08:58:07 -0500

> On Wed, Jan 23, 2019 at 05:55:52PM +0800, Jason Wang wrote:
>> This series tries to access virtqueue metadata through kernel virtual
>> address instead of copy_user() friends since they had too much
>> overheads like checks, spec barriers or even hardware feature
>> toggling.
>> 
>> Test shows about 24% improvement on TX PPS. It should benefit other
>> cases as well.
> 
> ok I think this addresses most comments but it's a big change and we
> just started 1.1 review so to pls give me a week to review this ok?

Ok. :)

^ permalink raw reply

* Re: [PATCH 0/5 v3] Fix virtio-blk issue with SWIOTLB
From: Michael S. Tsirkin @ 2019-01-23 18:51 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
In-Reply-To: <20190123163049.24863-1-joro@8bytes.org>

On Wed, Jan 23, 2019 at 05:30:44PM +0100, Joerg Roedel wrote:
> Hi,
> 
> here is the third 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/
> 
> 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.


OK looks good to me.
I will park this in my tree for now this way it will get
testing in linux-next.
Can I get an ack from DMA maintainers on the DMA bits for
merging this in 5.0?

> Changes to v2 are:
> 
> 	* Check if SWIOTLB is active before returning its limit in
> 	  dma_direct_max_mapping_size()
> 
> 	* Only apply the maximum segment limit in virtio-blk when
> 	  DMA-API is used for the vring
> 
> 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
> 
>  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         | 10 ++++++++++
>  7 files changed, 66 insertions(+), 4 deletions(-)
> 
> -- 
> 2.17.1

^ permalink raw reply

* Re: [Xen-devel] [RFC] virtio_ring: check dma_mem for xen_domain
From: hch @ 2019-01-23 21:14 UTC (permalink / raw)
  To: Stefano Stabellini
  Cc: jgross, Peng Fan, mst@redhat.com,
	linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, hch@infradead.org,
	luto, xen-devel@lists.xenproject.org, boris.ostrovsky
In-Reply-To: <alpine.DEB.2.10.1901230935280.17936@sstabellini-ThinkPad-X260>

On Wed, Jan 23, 2019 at 01:04:33PM -0800, Stefano Stabellini wrote:
> If vring_use_dma_api is actually supposed to return true when
> dma_dev->dma_mem is set, then both Peng's patch and the patch I wrote
> are not fixing the real issue here.
> 
> I don't know enough about remoteproc to know where the problem actually
> lies though.

The problem is the following:

Devices can declare a specific memory region that they want to use when
the driver calls dma_alloc_coherent for the device, this is done using
the shared-dma-pool DT attribute, which comes in two variants that
would be a little to much to explain here.

remoteproc makes use of that because apparently the device can
only communicate using that region.  But it then feeds back memory
obtained with dma_alloc_coherent into the virtio code.  For that
it calls vmalloc_to_page on the dma_alloc_coherent, which is a huge
no-go for the ĐMA API and only worked accidentally on a few platform,
and apparently arm64 just changed a few internals that made it stop
working for remoteproc.

The right answer is to not use the DMA API to allocate memory from
a device-speficic region, but to tie the driver directly into the
DT reserved memory API in a way that allows it to easilt obtain
a struct device for it.

This is orthogonal to another issue, and that is that hardware
virtio devices really always need to use the DMA API, otherwise
we'll bypass such features as the device specific DMA pools,
DMA offsets, cache flushing, etc, etc.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply

* Re: [PATCH 0/5 v3] Fix virtio-blk issue with SWIOTLB
From: Konrad Rzeszutek Wilk @ 2019-01-23 21:14 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: Jens Axboe, jroedel, brijesh.singh, Joerg Roedel, jon.grimm,
	jfehlig, linux-kernel, virtualization, linux-block, iommu,
	Christoph Hellwig
In-Reply-To: <20190123135000-mutt-send-email-mst@kernel.org>

On Wed, Jan 23, 2019 at 01:51:29PM -0500, Michael S. Tsirkin wrote:
> On Wed, Jan 23, 2019 at 05:30:44PM +0100, Joerg Roedel wrote:
> > Hi,
> > 
> > here is the third 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/
> > 
> > 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.
> 
> 
> OK looks good to me.
> I will park this in my tree for now this way it will get
> testing in linux-next.
> Can I get an ack from DMA maintainers on the DMA bits for
> merging this in 5.0?

You got mine (SWIOTBL is my area).
> 
> > Changes to v2 are:
> > 
> > 	* Check if SWIOTLB is active before returning its limit in
> > 	  dma_direct_max_mapping_size()
> > 
> > 	* Only apply the maximum segment limit in virtio-blk when
> > 	  DMA-API is used for the vring
> > 
> > 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
> > 
> >  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         | 10 ++++++++++
> >  7 files changed, 66 insertions(+), 4 deletions(-)
> > 
> > -- 
> > 2.17.1

^ permalink raw reply

* Re: [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
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
In-Reply-To: <20190123163049.24863-3-joro@8bytes.org>

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

* Re: [PATCH 1/5] swiotlb: Introduce swiotlb_max_mapping_size()
From: Christoph Hellwig @ 2019-01-23 21:28 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
In-Reply-To: <20190123163049.24863-2-joro@8bytes.org>

On Wed, Jan 23, 2019 at 05:30:45PM +0100, Joerg Roedel wrote:
> +extern size_t swiotlb_max_mapping_size(struct device *dev);

No need for the extern keyword on function declarations in headers.

^ permalink raw reply

* Re: [PATCH 3/5] dma: Introduce dma_max_mapping_size()
From: Christoph Hellwig @ 2019-01-23 21:29 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
In-Reply-To: <20190123163049.24863-4-joro@8bytes.org>


This looks ok, but could really use some documentation in
Documentation/DMA-API.txt.

^ permalink raw reply

* Re: [PATCH 5/5] virtio-blk: Consider virtio_max_dma_size() for maximum segment size
From: Christoph Hellwig @ 2019-01-23 21:31 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
In-Reply-To: <20190123163049.24863-6-joro@8bytes.org>

On Wed, Jan 23, 2019 at 05:30:49PM +0100, Joerg Roedel wrote:
> +	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);

I wonder if we should just move the dma max segment size check
into blk_queue_max_segment_size so that all block drivers benefit
from it.  Even if not I think at least the SCSI midlayer should
be updated to support it.

Btw, I wonder why virtio-scsi sticks to the default segment size,
unlike virtio-blk.

^ permalink raw reply

* Re: [PATCH 5/5] virtio-blk: Consider virtio_max_dma_size() for maximum segment size
From: Michael S. Tsirkin @ 2019-01-23 22:25 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Jens Axboe, jroedel, brijesh.singh, Konrad Rzeszutek Wilk,
	Joerg Roedel, jon.grimm, jfehlig, linux-kernel, virtualization,
	linux-block, iommu, pbonzini, jsnow
In-Reply-To: <20190123213139.GD9032@lst.de>

On Wed, Jan 23, 2019 at 10:31:39PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 23, 2019 at 05:30:49PM +0100, Joerg Roedel wrote:
> > +	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);
> 
> I wonder if we should just move the dma max segment size check
> into blk_queue_max_segment_size so that all block drivers benefit
> from it.  Even if not I think at least the SCSI midlayer should
> be updated to support it.
> 
> Btw, I wonder why virtio-scsi sticks to the default segment size,
> unlike virtio-blk.

Well no one bothered exposing that through that device.
Why does virtio block have it? Hard for me to say. First driver version
had it already but QEMU does not seem to use it and it seems that it
never did.


-- 
MST

^ permalink raw reply

* Re: [PATCH net-next V4 5/5] vhost: access vq metadata through kernel virtual address
From: Jason Wang @ 2019-01-24  4:07 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20190123085821-mutt-send-email-mst@kernel.org>


On 2019/1/23 下午10:08, Michael S. Tsirkin wrote:
> On Wed, Jan 23, 2019 at 05:55:57PM +0800, Jason Wang wrote:
>> It was noticed that the copy_user() friends that was used to access
>> virtqueue metdata tends to be very expensive for dataplane
>> implementation like vhost since it involves lots of software checks,
>> speculation barrier, hardware feature toggling (e.g SMAP). The
>> extra cost will be more obvious when transferring small packets since
>> the time spent on metadata accessing become more significant.
>>
>> This patch tries to eliminate those overheads by accessing them
>> through kernel virtual address by vmap(). To make the pages can be
>> migrated, instead of pinning them through GUP, we use MMU notifiers to
>> invalidate vmaps and re-establish vmaps during each round of metadata
>> prefetching if necessary. For devices that doesn't use metadata
>> prefetching, the memory accessors fallback to normal copy_user()
>> implementation gracefully. The invalidation was synchronized with
>> datapath through vq mutex, and in order to avoid hold vq mutex during
>> range checking, MMU notifier was teared down when trying to modify vq
>> metadata.
>>
>> Another thing is kernel lacks efficient solution for tracking dirty
>> pages by vmap(), this will lead issues if vhost is using file backed
>> memory which needs care of writeback. This patch solves this issue by
>> just skipping the vma that is file backed and fallback to normal
>> copy_user() friends. This might introduce some overheads for file
>> backed users but consider this use case is rare we could do
>> optimizations on top.
>>
>> Note that this was only done when device IOTLB is not enabled. We
>> could use similar method to optimize it in the future.
>>
>> Tests shows at most about 22% improvement on TX PPS when using
>> virtio-user + vhost_net + xdp1 + TAP on 2.6GHz Broadwell:
>>
>>          SMAP on | SMAP off
>> Before: 5.0Mpps | 6.6Mpps
>> After:  6.1Mpps | 7.4Mpps
>>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>
> So this is the bulk of the change.
> Threee things that I need to look into
> - Are there any security issues with bypassing the speculation barrier
>    that is normally present after access_ok?


If we can make sure the bypassing was only used in a kthread (vhost), it 
should be fine I think.


> - How hard does the special handling for
>    file backed storage make testing?


It's as simple as un-commenting vhost_can_vmap()? Or I can try to hack 
qemu or dpdk to test this.


>    On the one hand we could add a module parameter to
>    force copy to/from user. on the other that's
>    another configuration we need to support.


That sounds sub-optimal since it leave the choice to users.


>    But iotlb is not using vmap, so maybe that's enough
>    for testing.
> - How hard is it to figure out which mode uses which code.
>
>
>
> Meanwhile, could you pls post data comparing this last patch with the
> below?  This removes the speculation barrier replacing it with a
> (useless but at least more lightweight) data dependency.


SMAP off

Your patch: 7.2MPPs

vmap: 7.4Mpps

I don't test SMAP on, since it will be much slow for sure.

Thanks


>
> Thanks!
>
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index bac939af8dbb..352ee7e14476 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -739,7 +739,7 @@ static int vhost_copy_to_user(struct vhost_virtqueue *vq, void __user *to,
>   	int ret;
>   
>   	if (!vq->iotlb)
> -		return __copy_to_user(to, from, size);
> +		return copy_to_user(to, from, size);
>   	else {
>   		/* This function should be called after iotlb
>   		 * prefetch, which means we're sure that all vq
> @@ -752,7 +752,7 @@ static int vhost_copy_to_user(struct vhost_virtqueue *vq, void __user *to,
>   				     VHOST_ADDR_USED);
>   
>   		if (uaddr)
> -			return __copy_to_user(uaddr, from, size);
> +			return copy_to_user(uaddr, from, size);
>   
>   		ret = translate_desc(vq, (u64)(uintptr_t)to, size, vq->iotlb_iov,
>   				     ARRAY_SIZE(vq->iotlb_iov),
> @@ -774,7 +774,7 @@ static int vhost_copy_from_user(struct vhost_virtqueue *vq, void *to,
>   	int ret;
>   
>   	if (!vq->iotlb)
> -		return __copy_from_user(to, from, size);
> +		return copy_from_user(to, from, size);
>   	else {
>   		/* This function should be called after iotlb
>   		 * prefetch, which means we're sure that vq
> @@ -787,7 +787,7 @@ static int vhost_copy_from_user(struct vhost_virtqueue *vq, void *to,
>   		struct iov_iter f;
>   
>   		if (uaddr)
> -			return __copy_from_user(to, uaddr, size);
> +			return copy_from_user(to, uaddr, size);
>   
>   		ret = translate_desc(vq, (u64)(uintptr_t)from, size, vq->iotlb_iov,
>   				     ARRAY_SIZE(vq->iotlb_iov),
> @@ -855,13 +855,13 @@ static inline void __user *__vhost_get_user(struct vhost_virtqueue *vq,
>   ({ \
>   	int ret = -EFAULT; \
>   	if (!vq->iotlb) { \
> -		ret = __put_user(x, ptr); \
> +		ret = put_user(x, ptr); \
>   	} else { \
>   		__typeof__(ptr) to = \
>   			(__typeof__(ptr)) __vhost_get_user(vq, ptr,	\
>   					  sizeof(*ptr), VHOST_ADDR_USED); \
>   		if (to != NULL) \
> -			ret = __put_user(x, to); \
> +			ret = put_user(x, to); \
>   		else \
>   			ret = -EFAULT;	\
>   	} \
> @@ -872,14 +872,14 @@ static inline void __user *__vhost_get_user(struct vhost_virtqueue *vq,
>   ({ \
>   	int ret; \
>   	if (!vq->iotlb) { \
> -		ret = __get_user(x, ptr); \
> +		ret = get_user(x, ptr); \
>   	} else { \
>   		__typeof__(ptr) from = \
>   			(__typeof__(ptr)) __vhost_get_user(vq, ptr, \
>   							   sizeof(*ptr), \
>   							   type); \
>   		if (from != NULL) \
> -			ret = __get_user(x, from); \
> +			ret = get_user(x, from); \
>   		else \
>   			ret = -EFAULT; \
>   	} \
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply

* Re: [PATCH net-next V4 5/5] vhost: access vq metadata through kernel virtual address
From: Jason Wang @ 2019-01-24  4:11 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <335ba55b-087f-4b35-6311-540070b9647f@redhat.com>


On 2019/1/24 下午12:07, Jason Wang wrote:
>
> On 2019/1/23 下午10:08, Michael S. Tsirkin wrote:
>> On Wed, Jan 23, 2019 at 05:55:57PM +0800, Jason Wang wrote:
>>> It was noticed that the copy_user() friends that was used to access
>>> virtqueue metdata tends to be very expensive for dataplane
>>> implementation like vhost since it involves lots of software checks,
>>> speculation barrier, hardware feature toggling (e.g SMAP). The
>>> extra cost will be more obvious when transferring small packets since
>>> the time spent on metadata accessing become more significant.
>>>
>>> This patch tries to eliminate those overheads by accessing them
>>> through kernel virtual address by vmap(). To make the pages can be
>>> migrated, instead of pinning them through GUP, we use MMU notifiers to
>>> invalidate vmaps and re-establish vmaps during each round of metadata
>>> prefetching if necessary. For devices that doesn't use metadata
>>> prefetching, the memory accessors fallback to normal copy_user()
>>> implementation gracefully. The invalidation was synchronized with
>>> datapath through vq mutex, and in order to avoid hold vq mutex during
>>> range checking, MMU notifier was teared down when trying to modify vq
>>> metadata.
>>>
>>> Another thing is kernel lacks efficient solution for tracking dirty
>>> pages by vmap(), this will lead issues if vhost is using file backed
>>> memory which needs care of writeback. This patch solves this issue by
>>> just skipping the vma that is file backed and fallback to normal
>>> copy_user() friends. This might introduce some overheads for file
>>> backed users but consider this use case is rare we could do
>>> optimizations on top.
>>>
>>> Note that this was only done when device IOTLB is not enabled. We
>>> could use similar method to optimize it in the future.
>>>
>>> Tests shows at most about 22% improvement on TX PPS when using
>>> virtio-user + vhost_net + xdp1 + TAP on 2.6GHz Broadwell:
>>>
>>>          SMAP on | SMAP off
>>> Before: 5.0Mpps | 6.6Mpps
>>> After:  6.1Mpps | 7.4Mpps
>>>
>>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>>
>> So this is the bulk of the change.
>> Threee things that I need to look into
>> - Are there any security issues with bypassing the speculation barrier
>>    that is normally present after access_ok?
>
>
> If we can make sure the bypassing was only used in a kthread (vhost), 
> it should be fine I think.
>
>
>> - How hard does the special handling for
>>    file backed storage make testing?
>
>
> It's as simple as un-commenting vhost_can_vmap()? Or I can try to hack 
> qemu or dpdk to test this.
>
>
>>    On the one hand we could add a module parameter to
>>    force copy to/from user. on the other that's
>>    another configuration we need to support.
>
>
> That sounds sub-optimal since it leave the choice to users.
>
>
>>    But iotlb is not using vmap, so maybe that's enough
>>    for testing.
>> - How hard is it to figure out which mode uses which code.


It's as simple as tracing __get_user() usage in vhost process?

Thanks


>>
>>
>>
>> Meanwhile, could you pls post data comparing this last patch with the
>> below?  This removes the speculation barrier replacing it with a
>> (useless but at least more lightweight) data dependency.
>
>
> SMAP off
>
> Your patch: 7.2MPPs
>
> vmap: 7.4Mpps
>
> I don't test SMAP on, since it will be much slow for sure.
>
> Thanks
>
>
>>
>> Thanks!
>>
>>
>> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
>> index bac939af8dbb..352ee7e14476 100644
>> --- a/drivers/vhost/vhost.c
>> +++ b/drivers/vhost/vhost.c
>> @@ -739,7 +739,7 @@ static int vhost_copy_to_user(struct 
>> vhost_virtqueue *vq, void __user *to,
>>       int ret;
>>         if (!vq->iotlb)
>> -        return __copy_to_user(to, from, size);
>> +        return copy_to_user(to, from, size);
>>       else {
>>           /* This function should be called after iotlb
>>            * prefetch, which means we're sure that all vq
>> @@ -752,7 +752,7 @@ static int vhost_copy_to_user(struct 
>> vhost_virtqueue *vq, void __user *to,
>>                        VHOST_ADDR_USED);
>>             if (uaddr)
>> -            return __copy_to_user(uaddr, from, size);
>> +            return copy_to_user(uaddr, from, size);
>>             ret = translate_desc(vq, (u64)(uintptr_t)to, size, 
>> vq->iotlb_iov,
>>                        ARRAY_SIZE(vq->iotlb_iov),
>> @@ -774,7 +774,7 @@ static int vhost_copy_from_user(struct 
>> vhost_virtqueue *vq, void *to,
>>       int ret;
>>         if (!vq->iotlb)
>> -        return __copy_from_user(to, from, size);
>> +        return copy_from_user(to, from, size);
>>       else {
>>           /* This function should be called after iotlb
>>            * prefetch, which means we're sure that vq
>> @@ -787,7 +787,7 @@ static int vhost_copy_from_user(struct 
>> vhost_virtqueue *vq, void *to,
>>           struct iov_iter f;
>>             if (uaddr)
>> -            return __copy_from_user(to, uaddr, size);
>> +            return copy_from_user(to, uaddr, size);
>>             ret = translate_desc(vq, (u64)(uintptr_t)from, size, 
>> vq->iotlb_iov,
>>                        ARRAY_SIZE(vq->iotlb_iov),
>> @@ -855,13 +855,13 @@ static inline void __user 
>> *__vhost_get_user(struct vhost_virtqueue *vq,
>>   ({ \
>>       int ret = -EFAULT; \
>>       if (!vq->iotlb) { \
>> -        ret = __put_user(x, ptr); \
>> +        ret = put_user(x, ptr); \
>>       } else { \
>>           __typeof__(ptr) to = \
>>               (__typeof__(ptr)) __vhost_get_user(vq, ptr,    \
>>                         sizeof(*ptr), VHOST_ADDR_USED); \
>>           if (to != NULL) \
>> -            ret = __put_user(x, to); \
>> +            ret = put_user(x, to); \
>>           else \
>>               ret = -EFAULT;    \
>>       } \
>> @@ -872,14 +872,14 @@ static inline void __user 
>> *__vhost_get_user(struct vhost_virtqueue *vq,
>>   ({ \
>>       int ret; \
>>       if (!vq->iotlb) { \
>> -        ret = __get_user(x, ptr); \
>> +        ret = get_user(x, ptr); \
>>       } else { \
>>           __typeof__(ptr) from = \
>>               (__typeof__(ptr)) __vhost_get_user(vq, ptr, \
>>                                  sizeof(*ptr), \
>>                                  type); \
>>           if (from != NULL) \
>> -            ret = __get_user(x, from); \
>> +            ret = get_user(x, from); \
>>           else \
>>               ret = -EFAULT; \
>>       } \
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply

* Re: [PATCH net-next V4 5/5] vhost: access vq metadata through kernel virtual address
From: Michael S. Tsirkin @ 2019-01-24  4:51 UTC (permalink / raw)
  To: Jason Wang; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <335ba55b-087f-4b35-6311-540070b9647f@redhat.com>

On Thu, Jan 24, 2019 at 12:07:54PM +0800, Jason Wang wrote:
> 
> On 2019/1/23 下午10:08, Michael S. Tsirkin wrote:
> > On Wed, Jan 23, 2019 at 05:55:57PM +0800, Jason Wang wrote:
> > > It was noticed that the copy_user() friends that was used to access
> > > virtqueue metdata tends to be very expensive for dataplane
> > > implementation like vhost since it involves lots of software checks,
> > > speculation barrier, hardware feature toggling (e.g SMAP). The
> > > extra cost will be more obvious when transferring small packets since
> > > the time spent on metadata accessing become more significant.
> > > 
> > > This patch tries to eliminate those overheads by accessing them
> > > through kernel virtual address by vmap(). To make the pages can be
> > > migrated, instead of pinning them through GUP, we use MMU notifiers to
> > > invalidate vmaps and re-establish vmaps during each round of metadata
> > > prefetching if necessary. For devices that doesn't use metadata
> > > prefetching, the memory accessors fallback to normal copy_user()
> > > implementation gracefully. The invalidation was synchronized with
> > > datapath through vq mutex, and in order to avoid hold vq mutex during
> > > range checking, MMU notifier was teared down when trying to modify vq
> > > metadata.
> > > 
> > > Another thing is kernel lacks efficient solution for tracking dirty
> > > pages by vmap(), this will lead issues if vhost is using file backed
> > > memory which needs care of writeback. This patch solves this issue by
> > > just skipping the vma that is file backed and fallback to normal
> > > copy_user() friends. This might introduce some overheads for file
> > > backed users but consider this use case is rare we could do
> > > optimizations on top.
> > > 
> > > Note that this was only done when device IOTLB is not enabled. We
> > > could use similar method to optimize it in the future.
> > > 
> > > Tests shows at most about 22% improvement on TX PPS when using
> > > virtio-user + vhost_net + xdp1 + TAP on 2.6GHz Broadwell:
> > > 
> > >          SMAP on | SMAP off
> > > Before: 5.0Mpps | 6.6Mpps
> > > After:  6.1Mpps | 7.4Mpps
> > > 
> > > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > 
> > So this is the bulk of the change.
> > Threee things that I need to look into
> > - Are there any security issues with bypassing the speculation barrier
> >    that is normally present after access_ok?
> 
> 
> If we can make sure the bypassing was only used in a kthread (vhost), it
> should be fine I think.
> 
> 
> > - How hard does the special handling for
> >    file backed storage make testing?
> 
> 
> It's as simple as un-commenting vhost_can_vmap()? Or I can try to hack qemu
> or dpdk to test this.
> 
> 
> >    On the one hand we could add a module parameter to
> >    force copy to/from user. on the other that's
> >    another configuration we need to support.
> 
> 
> That sounds sub-optimal since it leave the choice to users.
> 
> 
> >    But iotlb is not using vmap, so maybe that's enough
> >    for testing.
> > - How hard is it to figure out which mode uses which code.
> > 
> > 
> > 
> > Meanwhile, could you pls post data comparing this last patch with the
> > below?  This removes the speculation barrier replacing it with a
> > (useless but at least more lightweight) data dependency.
> 
> 
> SMAP off
> 
> Your patch: 7.2MPPs
> 
> vmap: 7.4Mpps
> 

Sounds more or less as expected. Up to 3% gain with vmap - I think
that's a bit higher than what we saw previously when we switched from
get_user to __get_user and that's probably because of all the
array_index_nospec trickery.

> I don't test SMAP on, since it will be much slow for sure.

Right. So bypassing SMAP remains the main reason to do vmap tricks.

> Thanks

> 
> > 
> > Thanks!
> > 
> > 
> > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > index bac939af8dbb..352ee7e14476 100644
> > --- a/drivers/vhost/vhost.c
> > +++ b/drivers/vhost/vhost.c
> > @@ -739,7 +739,7 @@ static int vhost_copy_to_user(struct vhost_virtqueue *vq, void __user *to,
> >   	int ret;
> >   	if (!vq->iotlb)
> > -		return __copy_to_user(to, from, size);
> > +		return copy_to_user(to, from, size);
> >   	else {
> >   		/* This function should be called after iotlb
> >   		 * prefetch, which means we're sure that all vq
> > @@ -752,7 +752,7 @@ static int vhost_copy_to_user(struct vhost_virtqueue *vq, void __user *to,
> >   				     VHOST_ADDR_USED);
> >   		if (uaddr)
> > -			return __copy_to_user(uaddr, from, size);
> > +			return copy_to_user(uaddr, from, size);
> >   		ret = translate_desc(vq, (u64)(uintptr_t)to, size, vq->iotlb_iov,
> >   				     ARRAY_SIZE(vq->iotlb_iov),
> > @@ -774,7 +774,7 @@ static int vhost_copy_from_user(struct vhost_virtqueue *vq, void *to,
> >   	int ret;
> >   	if (!vq->iotlb)
> > -		return __copy_from_user(to, from, size);
> > +		return copy_from_user(to, from, size);
> >   	else {
> >   		/* This function should be called after iotlb
> >   		 * prefetch, which means we're sure that vq
> > @@ -787,7 +787,7 @@ static int vhost_copy_from_user(struct vhost_virtqueue *vq, void *to,
> >   		struct iov_iter f;
> >   		if (uaddr)
> > -			return __copy_from_user(to, uaddr, size);
> > +			return copy_from_user(to, uaddr, size);
> >   		ret = translate_desc(vq, (u64)(uintptr_t)from, size, vq->iotlb_iov,
> >   				     ARRAY_SIZE(vq->iotlb_iov),
> > @@ -855,13 +855,13 @@ static inline void __user *__vhost_get_user(struct vhost_virtqueue *vq,
> >   ({ \
> >   	int ret = -EFAULT; \
> >   	if (!vq->iotlb) { \
> > -		ret = __put_user(x, ptr); \
> > +		ret = put_user(x, ptr); \
> >   	} else { \
> >   		__typeof__(ptr) to = \
> >   			(__typeof__(ptr)) __vhost_get_user(vq, ptr,	\
> >   					  sizeof(*ptr), VHOST_ADDR_USED); \
> >   		if (to != NULL) \
> > -			ret = __put_user(x, to); \
> > +			ret = put_user(x, to); \
> >   		else \
> >   			ret = -EFAULT;	\
> >   	} \
> > @@ -872,14 +872,14 @@ static inline void __user *__vhost_get_user(struct vhost_virtqueue *vq,
> >   ({ \
> >   	int ret; \
> >   	if (!vq->iotlb) { \
> > -		ret = __get_user(x, ptr); \
> > +		ret = get_user(x, ptr); \
> >   	} else { \
> >   		__typeof__(ptr) from = \
> >   			(__typeof__(ptr)) __vhost_get_user(vq, ptr, \
> >   							   sizeof(*ptr), \
> >   							   type); \
> >   		if (from != NULL) \
> > -			ret = __get_user(x, from); \
> > +			ret = get_user(x, from); \
> >   		else \
> >   			ret = -EFAULT; \
> >   	} \
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply

* Re: [PATCH net-next V4 5/5] vhost: access vq metadata through kernel virtual address
From: Michael S. Tsirkin @ 2019-01-24  4:53 UTC (permalink / raw)
  To: Jason Wang; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <4521d3d8-561e-53f5-98e1-bf7ace003701@redhat.com>

On Thu, Jan 24, 2019 at 12:11:28PM +0800, Jason Wang wrote:
> 
> On 2019/1/24 下午12:07, Jason Wang wrote:
> > 
> > On 2019/1/23 下午10:08, Michael S. Tsirkin wrote:
> > > On Wed, Jan 23, 2019 at 05:55:57PM +0800, Jason Wang wrote:
> > > > It was noticed that the copy_user() friends that was used to access
> > > > virtqueue metdata tends to be very expensive for dataplane
> > > > implementation like vhost since it involves lots of software checks,
> > > > speculation barrier, hardware feature toggling (e.g SMAP). The
> > > > extra cost will be more obvious when transferring small packets since
> > > > the time spent on metadata accessing become more significant.
> > > > 
> > > > This patch tries to eliminate those overheads by accessing them
> > > > through kernel virtual address by vmap(). To make the pages can be
> > > > migrated, instead of pinning them through GUP, we use MMU notifiers to
> > > > invalidate vmaps and re-establish vmaps during each round of metadata
> > > > prefetching if necessary. For devices that doesn't use metadata
> > > > prefetching, the memory accessors fallback to normal copy_user()
> > > > implementation gracefully. The invalidation was synchronized with
> > > > datapath through vq mutex, and in order to avoid hold vq mutex during
> > > > range checking, MMU notifier was teared down when trying to modify vq
> > > > metadata.
> > > > 
> > > > Another thing is kernel lacks efficient solution for tracking dirty
> > > > pages by vmap(), this will lead issues if vhost is using file backed
> > > > memory which needs care of writeback. This patch solves this issue by
> > > > just skipping the vma that is file backed and fallback to normal
> > > > copy_user() friends. This might introduce some overheads for file
> > > > backed users but consider this use case is rare we could do
> > > > optimizations on top.
> > > > 
> > > > Note that this was only done when device IOTLB is not enabled. We
> > > > could use similar method to optimize it in the future.
> > > > 
> > > > Tests shows at most about 22% improvement on TX PPS when using
> > > > virtio-user + vhost_net + xdp1 + TAP on 2.6GHz Broadwell:
> > > > 
> > > >          SMAP on | SMAP off
> > > > Before: 5.0Mpps | 6.6Mpps
> > > > After:  6.1Mpps | 7.4Mpps
> > > > 
> > > > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > > 
> > > So this is the bulk of the change.
> > > Threee things that I need to look into
> > > - Are there any security issues with bypassing the speculation barrier
> > >    that is normally present after access_ok?
> > 
> > 
> > If we can make sure the bypassing was only used in a kthread (vhost), it
> > should be fine I think.
> > 
> > 
> > > - How hard does the special handling for
> > >    file backed storage make testing?
> > 
> > 
> > It's as simple as un-commenting vhost_can_vmap()? Or I can try to hack
> > qemu or dpdk to test this.
> > 
> > 
> > >    On the one hand we could add a module parameter to
> > >    force copy to/from user. on the other that's
> > >    another configuration we need to support.
> > 
> > 
> > That sounds sub-optimal since it leave the choice to users.
> > 
> > 
> > >    But iotlb is not using vmap, so maybe that's enough
> > >    for testing.
> > > - How hard is it to figure out which mode uses which code.
> 
> 
> It's as simple as tracing __get_user() usage in vhost process?
> 
> Thanks

Well there are now mtu notifiers etc etc. It's hardly as well
contained as that.


> 
> > > 
> > > 
> > > 
> > > Meanwhile, could you pls post data comparing this last patch with the
> > > below?  This removes the speculation barrier replacing it with a
> > > (useless but at least more lightweight) data dependency.
> > 
> > 
> > SMAP off
> > 
> > Your patch: 7.2MPPs
> > 
> > vmap: 7.4Mpps
> > 
> > I don't test SMAP on, since it will be much slow for sure.
> > 
> > Thanks
> > 
> > 
> > > 
> > > Thanks!
> > > 
> > > 
> > > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > > index bac939af8dbb..352ee7e14476 100644
> > > --- a/drivers/vhost/vhost.c
> > > +++ b/drivers/vhost/vhost.c
> > > @@ -739,7 +739,7 @@ static int vhost_copy_to_user(struct
> > > vhost_virtqueue *vq, void __user *to,
> > >       int ret;
> > >         if (!vq->iotlb)
> > > -        return __copy_to_user(to, from, size);
> > > +        return copy_to_user(to, from, size);
> > >       else {
> > >           /* This function should be called after iotlb
> > >            * prefetch, which means we're sure that all vq
> > > @@ -752,7 +752,7 @@ static int vhost_copy_to_user(struct
> > > vhost_virtqueue *vq, void __user *to,
> > >                        VHOST_ADDR_USED);
> > >             if (uaddr)
> > > -            return __copy_to_user(uaddr, from, size);
> > > +            return copy_to_user(uaddr, from, size);
> > >             ret = translate_desc(vq, (u64)(uintptr_t)to, size,
> > > vq->iotlb_iov,
> > >                        ARRAY_SIZE(vq->iotlb_iov),
> > > @@ -774,7 +774,7 @@ static int vhost_copy_from_user(struct
> > > vhost_virtqueue *vq, void *to,
> > >       int ret;
> > >         if (!vq->iotlb)
> > > -        return __copy_from_user(to, from, size);
> > > +        return copy_from_user(to, from, size);
> > >       else {
> > >           /* This function should be called after iotlb
> > >            * prefetch, which means we're sure that vq
> > > @@ -787,7 +787,7 @@ static int vhost_copy_from_user(struct
> > > vhost_virtqueue *vq, void *to,
> > >           struct iov_iter f;
> > >             if (uaddr)
> > > -            return __copy_from_user(to, uaddr, size);
> > > +            return copy_from_user(to, uaddr, size);
> > >             ret = translate_desc(vq, (u64)(uintptr_t)from, size,
> > > vq->iotlb_iov,
> > >                        ARRAY_SIZE(vq->iotlb_iov),
> > > @@ -855,13 +855,13 @@ static inline void __user
> > > *__vhost_get_user(struct vhost_virtqueue *vq,
> > >   ({ \
> > >       int ret = -EFAULT; \
> > >       if (!vq->iotlb) { \
> > > -        ret = __put_user(x, ptr); \
> > > +        ret = put_user(x, ptr); \
> > >       } else { \
> > >           __typeof__(ptr) to = \
> > >               (__typeof__(ptr)) __vhost_get_user(vq, ptr,    \
> > >                         sizeof(*ptr), VHOST_ADDR_USED); \
> > >           if (to != NULL) \
> > > -            ret = __put_user(x, to); \
> > > +            ret = put_user(x, to); \
> > >           else \
> > >               ret = -EFAULT;    \
> > >       } \
> > > @@ -872,14 +872,14 @@ static inline void __user
> > > *__vhost_get_user(struct vhost_virtqueue *vq,
> > >   ({ \
> > >       int ret; \
> > >       if (!vq->iotlb) { \
> > > -        ret = __get_user(x, ptr); \
> > > +        ret = get_user(x, ptr); \
> > >       } else { \
> > >           __typeof__(ptr) from = \
> > >               (__typeof__(ptr)) __vhost_get_user(vq, ptr, \
> > >                                  sizeof(*ptr), \
> > >                                  type); \
> > >           if (from != NULL) \
> > > -            ret = __get_user(x, from); \
> > > +            ret = get_user(x, from); \
> > >           else \
> > >               ret = -EFAULT; \
> > >       } \
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply

* Re: [PATCH 1/5] swiotlb: Introduce swiotlb_max_mapping_size()
From: Joerg Roedel @ 2019-01-24  8:24 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
In-Reply-To: <20190123212813.GB9032@lst.de>

On Wed, Jan 23, 2019 at 10:28:13PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 23, 2019 at 05:30:45PM +0100, Joerg Roedel wrote:
> > +extern size_t swiotlb_max_mapping_size(struct device *dev);
> 
> No need for the extern keyword on function declarations in headers.

Right, but all other function declarations in that header file have
'extern' too, so I added it also for that one.

Regards,

	Joerg

^ permalink raw reply

* Re: [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
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
In-Reply-To: <20190123212755.GA9032@lst.de>

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

* Re: [PATCH 5/5] virtio-blk: Consider virtio_max_dma_size() for maximum segment size
From: Joerg Roedel @ 2019-01-24  8:40 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
In-Reply-To: <20190123213139.GD9032@lst.de>

On Wed, Jan 23, 2019 at 10:31:39PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 23, 2019 at 05:30:49PM +0100, Joerg Roedel wrote:
> > +	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);
> 
> I wonder if we should just move the dma max segment size check
> into blk_queue_max_segment_size so that all block drivers benefit
> from it.  Even if not I think at least the SCSI midlayer should
> be updated to support it.

In that case the limit would also apply to virtio-blk even if it doesn't
use the DMA-API. If that is acceptable we can move the check to
blk_queue_max_segment_size().

Regards,

	Joerg

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox