* Re: [PATCH RFC] virtio: hint if callbacks surprisingly might sleep
From: Michael S. Tsirkin @ 2019-01-31 15:27 UTC (permalink / raw)
To: Cornelia Huck; +Cc: Halil Pasic, linux-s390, linux-kernel, virtualization
In-Reply-To: <20190131125314.29647-1-cohuck@redhat.com>
On Thu, Jan 31, 2019 at 01:53:14PM +0100, Cornelia Huck wrote:
> A virtio transport is free to implement some of the callbacks in
> virtio_config_ops in a matter that they cannot be called from
> atomic context (e.g. virtio-ccw, which maps a lot of the callbacks
> to channel I/O, which is an inherently asynchronous mechanism).
> This can be very surprising for developers using the much more
> common virtio-pci transport, just to find out that things break
> when used on s390.
>
> The documentation for virtio_config_ops now contains a comment
> explaining this, but it makes sense to add a might_sleep() annotation
> to various wrapper functions in the virtio core to avoid surprises
> later.
>
> Note that annotations are NOT added to two classes of calls:
> - direct calls from device drivers (all current callers should be
> fine, however)
> - calls which clearly won't be made from atomic context (such as
> those ultimately coming in via the driver core)
>
> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Makes sense to me. I don't think we should push our luck in
this release though, better defer until the merge window.
> ---
>
> I think it is safe to add this now that the issues with the balloon
> have been fixed.
>
> Note that this is not bulletproof (nor is it inteded to be). The
> intention is to make it easier for people to catch problems earlier.
>
> ---
> drivers/virtio/virtio.c | 2 ++
> include/linux/virtio_config.h | 13 +++++++++++++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> index 59e36ef4920f..98b30f54342c 100644
> --- a/drivers/virtio/virtio.c
> +++ b/drivers/virtio/virtio.c
> @@ -161,6 +161,7 @@ EXPORT_SYMBOL_GPL(virtio_config_enable);
>
> void virtio_add_status(struct virtio_device *dev, unsigned int status)
> {
> + might_sleep();
> dev->config->set_status(dev, dev->config->get_status(dev) | status);
> }
> EXPORT_SYMBOL_GPL(virtio_add_status);
> @@ -170,6 +171,7 @@ int virtio_finalize_features(struct virtio_device *dev)
> int ret = dev->config->finalize_features(dev);
> unsigned status;
>
> + might_sleep();
> if (ret)
> return ret;
>
> diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
> index 987b6491b946..bb4cc4910750 100644
> --- a/include/linux/virtio_config.h
> +++ b/include/linux/virtio_config.h
> @@ -290,6 +290,7 @@ static inline __virtio64 cpu_to_virtio64(struct virtio_device *vdev, u64 val)
> /* Config space accessors. */
> #define virtio_cread(vdev, structname, member, ptr) \
> do { \
> + might_sleep(); \
> /* Must match the member's type, and be integer */ \
> if (!typecheck(typeof((((structname*)0)->member)), *(ptr))) \
> (*ptr) = 1; \
> @@ -319,6 +320,7 @@ static inline __virtio64 cpu_to_virtio64(struct virtio_device *vdev, u64 val)
> /* Config space accessors. */
> #define virtio_cwrite(vdev, structname, member, ptr) \
> do { \
> + might_sleep(); \
> /* Must match the member's type, and be integer */ \
> if (!typecheck(typeof((((structname*)0)->member)), *(ptr))) \
> BUG_ON((*ptr) == 1); \
> @@ -358,6 +360,7 @@ static inline void __virtio_cread_many(struct virtio_device *vdev,
> vdev->config->generation(vdev) : 0;
> int i;
>
> + might_sleep();
> do {
> old = gen;
>
> @@ -380,6 +383,8 @@ static inline void virtio_cread_bytes(struct virtio_device *vdev,
> static inline u8 virtio_cread8(struct virtio_device *vdev, unsigned int offset)
> {
> u8 ret;
> +
> + might_sleep();
> vdev->config->get(vdev, offset, &ret, sizeof(ret));
> return ret;
> }
> @@ -387,6 +392,7 @@ static inline u8 virtio_cread8(struct virtio_device *vdev, unsigned int offset)
> static inline void virtio_cwrite8(struct virtio_device *vdev,
> unsigned int offset, u8 val)
> {
> + might_sleep();
> vdev->config->set(vdev, offset, &val, sizeof(val));
> }
>
> @@ -394,6 +400,8 @@ static inline u16 virtio_cread16(struct virtio_device *vdev,
> unsigned int offset)
> {
> u16 ret;
> +
> + might_sleep();
> vdev->config->get(vdev, offset, &ret, sizeof(ret));
> return virtio16_to_cpu(vdev, (__force __virtio16)ret);
> }
> @@ -401,6 +409,7 @@ static inline u16 virtio_cread16(struct virtio_device *vdev,
> static inline void virtio_cwrite16(struct virtio_device *vdev,
> unsigned int offset, u16 val)
> {
> + might_sleep();
> val = (__force u16)cpu_to_virtio16(vdev, val);
> vdev->config->set(vdev, offset, &val, sizeof(val));
> }
> @@ -409,6 +418,8 @@ static inline u32 virtio_cread32(struct virtio_device *vdev,
> unsigned int offset)
> {
> u32 ret;
> +
> + might_sleep();
> vdev->config->get(vdev, offset, &ret, sizeof(ret));
> return virtio32_to_cpu(vdev, (__force __virtio32)ret);
> }
> @@ -416,6 +427,7 @@ static inline u32 virtio_cread32(struct virtio_device *vdev,
> static inline void virtio_cwrite32(struct virtio_device *vdev,
> unsigned int offset, u32 val)
> {
> + might_sleep();
> val = (__force u32)cpu_to_virtio32(vdev, val);
> vdev->config->set(vdev, offset, &val, sizeof(val));
> }
> @@ -431,6 +443,7 @@ static inline u64 virtio_cread64(struct virtio_device *vdev,
> static inline void virtio_cwrite64(struct virtio_device *vdev,
> unsigned int offset, u64 val)
> {
> + might_sleep();
> val = (__force u64)cpu_to_virtio64(vdev, val);
> vdev->config->set(vdev, offset, &val, sizeof(val));
> }
> --
> 2.17.2
^ permalink raw reply
* Re: [PATCH RFC] virtio: hint if callbacks surprisingly might sleep
From: Cornelia Huck @ 2019-01-31 15:41 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Halil Pasic, linux-s390, linux-kernel, virtualization
In-Reply-To: <20190131102713-mutt-send-email-mst@kernel.org>
On Thu, 31 Jan 2019 10:27:53 -0500
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Thu, Jan 31, 2019 at 01:53:14PM +0100, Cornelia Huck wrote:
> > A virtio transport is free to implement some of the callbacks in
> > virtio_config_ops in a matter that they cannot be called from
> > atomic context (e.g. virtio-ccw, which maps a lot of the callbacks
> > to channel I/O, which is an inherently asynchronous mechanism).
> > This can be very surprising for developers using the much more
> > common virtio-pci transport, just to find out that things break
> > when used on s390.
> >
> > The documentation for virtio_config_ops now contains a comment
> > explaining this, but it makes sense to add a might_sleep() annotation
> > to various wrapper functions in the virtio core to avoid surprises
> > later.
> >
> > Note that annotations are NOT added to two classes of calls:
> > - direct calls from device drivers (all current callers should be
> > fine, however)
> > - calls which clearly won't be made from atomic context (such as
> > those ultimately coming in via the driver core)
> >
> > Signed-off-by: Cornelia Huck <cohuck@redhat.com>
>
>
> Makes sense to me. I don't think we should push our luck in
> this release though, better defer until the merge window.
Nod, that's definitely something for the next release.
^ permalink raw reply
* [PATCH 0/5 v6] Fix virtio-blk issue with SWIOTLB
From: Joerg Roedel @ 2019-01-31 16:33 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
Hi,
here is the next 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/
V4: https://lore.kernel.org/lkml/20190129084342.26030-1-joro@8bytes.org/
V5: https://lore.kernel.org/lkml/20190130164007.26497-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 v5 are:
- Changed patch 3 to uninline dma_max_mapping_size()
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 | 11 +++++++++++
include/linux/dma-mapping.h | 8 ++++++++
include/linux/swiotlb.h | 11 +++++++++++
include/linux/virtio.h | 2 ++
kernel/dma/direct.c | 11 +++++++++++
kernel/dma/mapping.c | 14 ++++++++++++++
kernel/dma/swiotlb.c | 14 ++++++++++++++
9 files changed, 85 insertions(+), 4 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH 1/5] swiotlb: Introduce swiotlb_max_mapping_size()
From: Joerg Roedel @ 2019-01-31 16:33 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
In-Reply-To: <20190131163403.11363-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.
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 | 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
* [PATCH 2/5] swiotlb: Add is_swiotlb_active() function
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
In-Reply-To: <20190131163403.11363-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.
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
* [PATCH 3/5] dma: Introduce dma_max_mapping_size()
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
In-Reply-To: <20190131163403.11363-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.
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
Documentation/DMA-API.txt | 8 ++++++++
include/linux/dma-mapping.h | 8 ++++++++
kernel/dma/direct.c | 11 +++++++++++
kernel/dma/mapping.c | 14 ++++++++++++++
4 files changed, 41 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..5b21f14802e1 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>
@@ -460,6 +463,7 @@ int dma_supported(struct device *dev, u64 mask);
int dma_set_mask(struct device *dev, u64 mask);
int dma_set_coherent_mask(struct device *dev, u64 mask);
u64 dma_get_required_mask(struct device *dev);
+size_t dma_max_mapping_size(struct device *dev);
#else /* CONFIG_HAS_DMA */
static inline dma_addr_t dma_map_page_attrs(struct device *dev,
struct page *page, size_t offset, size_t size,
@@ -561,6 +565,10 @@ static inline u64 dma_get_required_mask(struct device *dev)
{
return 0;
}
+static inline size_t dma_max_mapping_size(struct device *dev)
+{
+ return 0;
+}
#endif /* CONFIG_HAS_DMA */
static inline dma_addr_t dma_map_single_attrs(struct device *dev, void *ptr,
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;
+}
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index a11006b6d8e8..5753008ab286 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -357,3 +357,17 @@ void dma_cache_sync(struct device *dev, void *vaddr, size_t size,
ops->cache_sync(dev, vaddr, size, dir);
}
EXPORT_SYMBOL(dma_cache_sync);
+
+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;
+}
+EXPORT_SYMBOL_GPL(dma_max_mapping_size);
--
2.17.1
^ permalink raw reply related
* [PATCH 4/5] virtio: Introduce virtio_max_dma_size()
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
In-Reply-To: <20190131163403.11363-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.
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
drivers/virtio/virtio_ring.c | 11 +++++++++++
include/linux/virtio.h | 2 ++
2 files changed, 13 insertions(+)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index cd7e755484e3..8a31c6862b2b 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -266,6 +266,17 @@ 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;
+}
+EXPORT_SYMBOL_GPL(virtio_max_dma_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-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
In-Reply-To: <20190131163403.11363-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.
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
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] dma: Uninline dma_max_mapping_size()
From: Joerg Roedel @ 2019-01-31 16:34 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jens Axboe, Thomas.Lendacky, jroedel, brijesh.singh,
Konrad Rzeszutek Wilk, jon.grimm, jfehlig, linux-kernel,
virtualization, linux-block, iommu, Christoph Hellwig
In-Reply-To: <20190131094319-mutt-send-email-mst@kernel.org>
On Thu, Jan 31, 2019 at 09:43:51AM -0500, Michael S. Tsirkin wrote:
> OK. Joerg can you repost the series with this squashed
> and all acks applied?
Sure, sent out now as v6.
Regards,
Joerg
^ permalink raw reply
* Re: [PATCH net] virtio_net: Account for tx bytes and packets on sending xdp_frames
From: David Miller @ 2019-01-31 17:45 UTC (permalink / raw)
To: mst; +Cc: hawk, netdev, virtualization, dsahern
In-Reply-To: <20190131101516-mutt-send-email-mst@kernel.org>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Thu, 31 Jan 2019 10:25:17 -0500
> On Thu, Jan 31, 2019 at 08:40:30PM +0900, Toshiaki Makita wrote:
>> Previously virtnet_xdp_xmit() did not account for device tx counters,
>> which caused confusions.
>> To be consistent with SKBs, account them on freeing xdp_frames.
>>
>> Reported-by: David Ahern <dsahern@gmail.com>
>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>
> Well we count them on receive so I guess it makes sense for consistency
>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>
> however, I really wonder whether adding more and more standard net stack
> things like this will end up costing most of XDP its speed.
>
> Should we instead make sure *not* to account XDP packets
> in any counters at all? XDP programs can use maps
> to do their own counting...
This has been definitely a discussion point, and something we should
develop a clear, strong, policy on.
David, Jesper, care to chime in where we ended up in that last thread
discussion this?
^ permalink raw reply
* Re: [PATCH v6 00/27] x86: PIE support and option to extend KASLR randomization
From: Kees Cook @ 2019-01-31 19:59 UTC (permalink / raw)
To: Thomas Garnier
Cc: Kernel Hardening, Jan Kiszka, Pavel Machek, Andrey Ryabinin,
Christoph Lameter, Rafael Ávila de Espíndola,
linux-arch, Andi Kleen, Michael Ellerman, Sparse Mailing-list,
xen-devel, Alexander Popov, Len Brown, Linux PM list,
Nicholas Piggin, Cao jin, Mike Rapoport, Andy Lutomirski,
Dennis Zhou, Thomas Gleixner, nixiaoming, Michal Marek
In-Reply-To: <20190131192533.34130-1-thgarnie@chromium.org>
On Fri, Feb 1, 2019 at 8:28 AM Thomas Garnier <thgarnie@chromium.org> wrote:
> These patches make the changes necessary to build the kernel as Position
> Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
> the top 2G of the virtual address space. It allows to optionally extend the
> KASLR randomization range from 1G to 3G. The chosen range is the one currently
> available, future changes will allow the kernel module to have a wider
> randomization range.
This also lays the groundwork for doing compilation-unit-granularity
KASLR, as Kristen has been working on. With PIE working, the
relocations are more sane and boot-time reordering becomes possible
(or at least, it becomes the same logically as doing the work on
modules, etc).
--
Kees Cook
^ permalink raw reply
* Re: [PATCH net] virtio_net: Account for tx bytes and packets on sending xdp_frames
From: Jesper Dangaard Brouer @ 2019-01-31 20:15 UTC (permalink / raw)
To: David Miller
Cc: hawk, mst, netdev, dsahern, virtualization,
Toke Høiland-Jørgensen
In-Reply-To: <20190131.094523.2248120325911339180.davem@davemloft.net>
On Thu, 31 Jan 2019 09:45:23 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: "Michael S. Tsirkin" <mst@redhat.com>
> Date: Thu, 31 Jan 2019 10:25:17 -0500
>
> > On Thu, Jan 31, 2019 at 08:40:30PM +0900, Toshiaki Makita wrote:
> >> Previously virtnet_xdp_xmit() did not account for device tx counters,
> >> which caused confusions.
> >> To be consistent with SKBs, account them on freeing xdp_frames.
> >>
> >> Reported-by: David Ahern <dsahern@gmail.com>
> >> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> >
> > Well we count them on receive so I guess it makes sense for consistency
> >
> > Acked-by: Michael S. Tsirkin <mst@redhat.com>
> >
> > however, I really wonder whether adding more and more standard net stack
> > things like this will end up costing most of XDP its speed.
> >
> > Should we instead make sure *not* to account XDP packets
> > in any counters at all? XDP programs can use maps
> > to do their own counting...
>
> This has been definitely a discussion point, and something we should
> develop a clear, strong, policy on.
>
> David, Jesper, care to chime in where we ended up in that last thread
> discussion this?
IHMO packets RX and TX on a device need to be accounted, in standard
counters, regardless of XDP. For XDP RX the packet is counted as RX,
regardless if XDP choose to XDP_DROP. On XDP TX which is via
XDP_REDIRECT or XDP_TX, the driver that transmit the packet need to
account the packet in a TX counter (this if often delayed to DMA TX
completion handling). We cannot break the expectation that RX and TX
counter are visible to userspace stats tools. XDP should not make these
packets invisible.
Performance wise, I don't see an issue. As updating these counters
(packets and bytes) can be done as a bulk, either when driver NAPI RX
func ends, or in TX DMA completion, like most drivers already do today.
Further more, most drivers save this in per RX ring data-area, which
are only summed when userspace read these.
A separate question (and project) raised by David Ahern, was if we
should have more detailed stats on the different XDP action return
codes, as an easy means for sysadms to diagnose running XDP programs.
That is something that require more discussions, as it can impact
performance, and likely need to be opt-in. My opinion is yes we should
do this for the sake of better User eXperience, BUT *only* if we can find
a technical solution that does not hurt performance.
--Jesper
^ permalink raw reply
* Re: [PATCH v6 00/27] x86: PIE support and option to extend KASLR randomization
From: Konrad Rzeszutek Wilk @ 2019-01-31 21:40 UTC (permalink / raw)
To: Thomas Garnier
Cc: kernel-hardening, Jan Kiszka, Pavel Machek, Andrey Ryabinin,
Christoph Lameter, Rafael Ávila de Espíndola,
linux-arch, Andi Kleen, Michael Ellerman, linux-sparse, xen-devel,
Alexander Popov, Len Brown, linux-pm, Nicholas Piggin, Cao jin,
Mike Rapoport, Andy Lutomirski, Dennis Zhou, Thomas Gleixner,
nixiaoming, Michal Marek, Greg Kroah-Hartman
In-Reply-To: <20190131192533.34130-1-thgarnie@chromium.org>
On Thu, Jan 31, 2019 at 11:24:07AM -0800, Thomas Garnier wrote:
> There has been no major concern in the latest iterations. I am interested on
> what would be the best way to slowly integrate this patchset upstream.
One question that I was somehow expected in this cover letter - what
about all those lovely speculative bugs? As in say some one hasn't
updated their machine with the Spectre v3a microcode - wouldn't they
be able to get the kernel virtual address space?
In effect rendering all this hard-work not needed?
^ permalink raw reply
* Re: [PATCH net] virtio_net: Account for tx bytes and packets on sending xdp_frames
From: Toshiaki Makita @ 2019-02-01 1:53 UTC (permalink / raw)
To: Jesper Dangaard Brouer, David Miller
Cc: hawk, mst, netdev, virtualization,
Toke Høiland-Jørgensen, dsahern
In-Reply-To: <20190131211555.3b15c81f@carbon>
On 2019/02/01 5:15, Jesper Dangaard Brouer wrote:
> On Thu, 31 Jan 2019 09:45:23 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
>
>> From: "Michael S. Tsirkin" <mst@redhat.com>
>> Date: Thu, 31 Jan 2019 10:25:17 -0500
>>
>>> On Thu, Jan 31, 2019 at 08:40:30PM +0900, Toshiaki Makita wrote:
>>>> Previously virtnet_xdp_xmit() did not account for device tx counters,
>>>> which caused confusions.
>>>> To be consistent with SKBs, account them on freeing xdp_frames.
>>>>
>>>> Reported-by: David Ahern <dsahern@gmail.com>
>>>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>>>
>>> Well we count them on receive so I guess it makes sense for consistency
>>>
>>> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>>>
>>> however, I really wonder whether adding more and more standard net stack
>>> things like this will end up costing most of XDP its speed.
>>>
>>> Should we instead make sure *not* to account XDP packets
>>> in any counters at all? XDP programs can use maps
>>> to do their own counting...
>>
>> This has been definitely a discussion point, and something we should
>> develop a clear, strong, policy on.
>>
>> David, Jesper, care to chime in where we ended up in that last thread
>> discussion this?
>
> IHMO packets RX and TX on a device need to be accounted, in standard
> counters, regardless of XDP. For XDP RX the packet is counted as RX,
> regardless if XDP choose to XDP_DROP. On XDP TX which is via
> XDP_REDIRECT or XDP_TX, the driver that transmit the packet need to
> account the packet in a TX counter (this if often delayed to DMA TX
> completion handling). We cannot break the expectation that RX and TX
> counter are visible to userspace stats tools. XDP should not make these
> packets invisible.
>
> Performance wise, I don't see an issue. As updating these counters
> (packets and bytes) can be done as a bulk, either when driver NAPI RX
> func ends, or in TX DMA completion, like most drivers already do today.
> Further more, most drivers save this in per RX ring data-area, which
> are only summed when userspace read these.
Agreed.
> A separate question (and project) raised by David Ahern, was if we
> should have more detailed stats on the different XDP action return
> codes, as an easy means for sysadms to diagnose running XDP programs.
> That is something that require more discussions, as it can impact
> performance, and likely need to be opt-in. My opinion is yes we should
> do this for the sake of better User eXperience, BUT *only* if we can find
> a technical solution that does not hurt performance.
Basically the situation for the detailed stats is the same as standard
stats, at least in virtio_net. Stats are updated as a bulk, and the
counters reside in RX/TX ring structures.
Probably this way of implementation would be ok performance-wise?
But as other drivers may have different situations, if it is generally
difficult to avoid performance penalty I'm OK with making them opt-in as
a standard way.
--
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH v2 5/6] drm/virtio: drop fencing in virtio_gpu_resource_create_ioctl
From: Gerd Hoffmann @ 2019-02-01 7:23 UTC (permalink / raw)
To: Gurchetan Singh
Cc: David Airlie, open list, ML dri-devel,
open list:VIRTIO GPU DRIVER
In-Reply-To: <CAAfnVB=z36CtTsCiEy1uVTNvE9DVuSDKLNdMVFO+tBJqiQ7s1A@mail.gmail.com>
On Thu, Jan 31, 2019 at 11:04:31AM -0800, Gurchetan Singh wrote:
> On Wed, Jan 30, 2019 at 1:43 AM Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> > There is no need to wait for completion here.
> >
> > The host will process commands in submit order, so commands can
> > reference the new resource just fine even when queued up before
> > completion.
>
> Does virtio_gpu_execbuffer_ioctl also wait for completion for a host response?
No.
But you pass in a list of objects (drm_virtgpu_execbuffer->bo_handles)
used. They will all get reserved, so you can use DRM_IOCTL_VIRTGPU_WAIT
on any of these objects to wait for completion.
Recently the driver got support for returning a fence fd for the
execbuffer, which you can also use to wait for completion in case your
kernel is new enough.
> From the guest driver perspective, a fence is just implemented has a
> virtio 3D resource.
>
> https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c#L787
>
> The DRM_IOCTL_VIRTGPU_WAIT ioctl essentially waits for the reservation
> objects associated with that fence resource to become available. So
> the flow is:
>
> virtio_gpu_execbuffer_ioctl
> virtio_gpu_resource_create_ioctl with fence resource
> virtio_gpu_wait_ioctl with that fence resource --> associated with a
> GL wait on the host side
Oh. /me looks surprised.
Wasn't aware that userspace is doing *that*.
> Does this change modify this sequence of events?
Yes. DRM_IOCTL_VIRTGPU_WAIT will not wait any more. Guess I have to
scratch the patch then ...
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH v2 4/6] drm/virtio: params struct for virtio_gpu_cmd_create_resource_3d()
From: Gerd Hoffmann @ 2019-02-01 8:01 UTC (permalink / raw)
To: Noralf Trønnes
Cc: David Airlie, open list, dri-devel, open list:VIRTIO GPU DRIVER
In-Reply-To: <4d3064ef-9993-106a-74b5-73a29c08975e@tronnes.org>
On Thu, Jan 31, 2019 at 11:47:38AM +0100, Noralf Trønnes wrote:
>
>
> Den 30.01.2019 10.43, skrev Gerd Hoffmann:
> > Add 3d resource parameters to virtio_gpu_object_params struct. With
> > that in place we can use it for virtio_gpu_cmd_resource_create_3d()
> > calls.
> >
> > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> > ---
>
> You don't remove the struct virtio_gpu_resource_create_3d definition,
> but it looks like there's no users left?
virtio_gpu_cmd_resource_create_3d() still uses it (and has to, it is
part of the guest <-> host protocol).
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH 0/5 v6] Fix virtio-blk issue with SWIOTLB
From: Christoph Hellwig @ 2019-02-01 8:09 UTC (permalink / raw)
To: Joerg Roedel
Cc: Jens Axboe, Thomas.Lendacky, jon.grimm, brijesh.singh,
Konrad Rzeszutek Wilk, Michael S . Tsirkin, jfehlig, linux-kernel,
virtualization, linux-block, iommu, jroedel, Christoph Hellwig
In-Reply-To: <20190131163403.11363-1-joro@8bytes.org>
For some reason patch 5 didn't make it to my inbox, but assuming
nothing has changed this whole series looks good to me now.
^ permalink raw reply
* Re: [PATCH v2 2/6] drm/virtio: use struct to pass params to virtio_gpu_object_create()
From: Gerd Hoffmann @ 2019-02-01 8:10 UTC (permalink / raw)
To: Noralf Trønnes
Cc: David Airlie, open list, dri-devel, open list:VIRTIO GPU DRIVER
In-Reply-To: <46c0feb8-3a0d-eeac-180c-cb0f3147fe11@tronnes.org>
> > - ret = virtio_gpu_gem_create(file_priv, dev, args->size, &gobj,
> > + params.pinned = false,
>
> You have a comma here, but assigning to false isn't really necessary
> since the struct is zeroed. Same goes for the same assignment further down.
Hmm, yes, but it likewise isn't used, so I think I can just scratch it
altogether.
It's also wrong, virtio-gpu objects don't move around, so they are all
pinned. Not that this bug changes much in practice given virtio-gpu
supports a single kind of storage only, so there is no opportunity for
ttm to try move objects from one to another. I'll fix it nevertheless
in v3.
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH v2 4/6] drm/virtio: params struct for virtio_gpu_cmd_create_resource_3d()
From: Noralf Trønnes @ 2019-02-01 9:31 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: David Airlie, open list, dri-devel, open list:VIRTIO GPU DRIVER
In-Reply-To: <20190201080113.mhlzpyek62cfc5qe@sirius.home.kraxel.org>
Den 01.02.2019 09.01, skrev Gerd Hoffmann:
> On Thu, Jan 31, 2019 at 11:47:38AM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 30.01.2019 10.43, skrev Gerd Hoffmann:
>>> Add 3d resource parameters to virtio_gpu_object_params struct. With
>>> that in place we can use it for virtio_gpu_cmd_resource_create_3d()
>>> calls.
>>>
>>> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
>>> ---
>>
>> You don't remove the struct virtio_gpu_resource_create_3d definition,
>> but it looks like there's no users left?
>
> virtio_gpu_cmd_resource_create_3d() still uses it (and has to, it is
> part of the guest <-> host protocol).
>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH v3 0/2] vsock/virtio: fix issues on device hot-unplug
From: Stefano Garzarella @ 2019-02-01 11:42 UTC (permalink / raw)
To: Stefan Hajnoczi, David S. Miller
Cc: netdev, linux-kernel, kvm, virtualization
These patches try to handle the hot-unplug of vsock virtio transport device in
a proper way.
Maybe move the vsock_core_init()/vsock_core_exit() functions in the module_init
and module_exit of vsock_virtio_transport module can't be the best way, but the
architecture of vsock_core forces us to this approach for now.
The vsock_core proto_ops expect a valid pointer to the transport device, so we
can't call vsock_core_exit() until there are open sockets.
v2 -> v3:
- Rebased on master
v1 -> v2:
- Fixed commit message of patch 1.
- Added Reviewed-by, Acked-by tags by Stefan
Stefano Garzarella (2):
vsock/virtio: fix kernel panic after device hot-unplug
vsock/virtio: reset connected sockets on device removal
net/vmw_vsock/virtio_transport.c | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH v3 1/2] vsock/virtio: fix kernel panic after device hot-unplug
From: Stefano Garzarella @ 2019-02-01 11:42 UTC (permalink / raw)
To: Stefan Hajnoczi, David S. Miller
Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20190201114207.97217-1-sgarzare@redhat.com>
virtio_vsock_remove() invokes the vsock_core_exit() also if there
are opened sockets for the AF_VSOCK protocol family. In this way
the vsock "transport" pointer is set to NULL, triggering the
kernel panic at the first socket activity.
This patch move the vsock_core_init()/vsock_core_exit() in the
virtio_vsock respectively in module_init and module_exit functions,
that cannot be invoked until there are open sockets.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1609699
Reported-by: Yan Fu <yafu@redhat.com>
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
---
net/vmw_vsock/virtio_transport.c | 26 ++++++++++++++++++--------
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
index 5d3cce9e8744..9dae54698737 100644
--- a/net/vmw_vsock/virtio_transport.c
+++ b/net/vmw_vsock/virtio_transport.c
@@ -75,6 +75,9 @@ static u32 virtio_transport_get_local_cid(void)
{
struct virtio_vsock *vsock = virtio_vsock_get();
+ if (!vsock)
+ return VMADDR_CID_ANY;
+
return vsock->guest_cid;
}
@@ -584,10 +587,6 @@ static int virtio_vsock_probe(struct virtio_device *vdev)
virtio_vsock_update_guest_cid(vsock);
- ret = vsock_core_init(&virtio_transport.transport);
- if (ret < 0)
- goto out_vqs;
-
vsock->rx_buf_nr = 0;
vsock->rx_buf_max_nr = 0;
atomic_set(&vsock->queued_replies, 0);
@@ -618,8 +617,6 @@ static int virtio_vsock_probe(struct virtio_device *vdev)
mutex_unlock(&the_virtio_vsock_mutex);
return 0;
-out_vqs:
- vsock->vdev->config->del_vqs(vsock->vdev);
out:
kfree(vsock);
mutex_unlock(&the_virtio_vsock_mutex);
@@ -669,7 +666,6 @@ static void virtio_vsock_remove(struct virtio_device *vdev)
mutex_lock(&the_virtio_vsock_mutex);
the_virtio_vsock = NULL;
- vsock_core_exit();
mutex_unlock(&the_virtio_vsock_mutex);
vdev->config->del_vqs(vdev);
@@ -702,14 +698,28 @@ static int __init virtio_vsock_init(void)
virtio_vsock_workqueue = alloc_workqueue("virtio_vsock", 0, 0);
if (!virtio_vsock_workqueue)
return -ENOMEM;
+
ret = register_virtio_driver(&virtio_vsock_driver);
if (ret)
- destroy_workqueue(virtio_vsock_workqueue);
+ goto out_wq;
+
+ ret = vsock_core_init(&virtio_transport.transport);
+ if (ret)
+ goto out_vdr;
+
+ return 0;
+
+out_vdr:
+ unregister_virtio_driver(&virtio_vsock_driver);
+out_wq:
+ destroy_workqueue(virtio_vsock_workqueue);
return ret;
+
}
static void __exit virtio_vsock_exit(void)
{
+ vsock_core_exit();
unregister_virtio_driver(&virtio_vsock_driver);
destroy_workqueue(virtio_vsock_workqueue);
}
--
2.20.1
^ permalink raw reply related
* [PATCH v3 2/2] vsock/virtio: reset connected sockets on device removal
From: Stefano Garzarella @ 2019-02-01 11:42 UTC (permalink / raw)
To: Stefan Hajnoczi, David S. Miller
Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20190201114207.97217-1-sgarzare@redhat.com>
When the virtio transport device disappear, we should reset all
connected sockets in order to inform the users.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
---
net/vmw_vsock/virtio_transport.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
index 9dae54698737..15eb5d3d4750 100644
--- a/net/vmw_vsock/virtio_transport.c
+++ b/net/vmw_vsock/virtio_transport.c
@@ -634,6 +634,9 @@ static void virtio_vsock_remove(struct virtio_device *vdev)
flush_work(&vsock->event_work);
flush_work(&vsock->send_pkt_work);
+ /* Reset all connected sockets when the device disappear */
+ vsock_for_each_connected_socket(virtio_vsock_reset_sock);
+
vdev->config->reset(vdev);
mutex_lock(&vsock->rx_lock);
--
2.20.1
^ permalink raw reply related
* [PATCH] virtio: drop internal struct from UAPI
From: Michael S. Tsirkin @ 2019-02-01 22:16 UTC (permalink / raw)
To: linux-kernel; +Cc: virtualization
There's no reason to expose struct vring_packed in UAPI - if we do we
won't be able to change or drop it, and it's not part of any interface.
Let's move it to virtio_ring.c
Cc: Tiwei Bie <tiwei.bie@intel.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/virtio/virtio_ring.c | 7 ++++++-
include/uapi/linux/virtio_ring.h | 10 ----------
2 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 412e0c431d87..1c85b3423182 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -152,7 +152,12 @@ struct vring_virtqueue {
/* Available for packed ring */
struct {
/* Actual memory layout for this queue. */
- struct vring_packed vring;
+ struct {
+ unsigned int num;
+ struct vring_packed_desc *desc;
+ struct vring_packed_desc_event *driver;
+ struct vring_packed_desc_event *device;
+ } vring;
/* Driver ring wrap counter. */
bool avail_wrap_counter;
diff --git a/include/uapi/linux/virtio_ring.h b/include/uapi/linux/virtio_ring.h
index 2414f8af26b3..4c4e24c291a5 100644
--- a/include/uapi/linux/virtio_ring.h
+++ b/include/uapi/linux/virtio_ring.h
@@ -213,14 +213,4 @@ struct vring_packed_desc {
__le16 flags;
};
-struct vring_packed {
- unsigned int num;
-
- struct vring_packed_desc *desc;
-
- struct vring_packed_desc_event *driver;
-
- struct vring_packed_desc_event *device;
-};
-
#endif /* _UAPI_LINUX_VIRTIO_RING_H */
--
MST
^ permalink raw reply related
* Re: [PATCH] virtio: drop internal struct from UAPI
From: Jason Wang @ 2019-02-02 3:18 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel; +Cc: virtualization
In-Reply-To: <20190201221553.7210-1-mst@redhat.com>
On 2019/2/2 上午6:16, Michael S. Tsirkin wrote:
> There's no reason to expose struct vring_packed in UAPI - if we do we
> won't be able to change or drop it, and it's not part of any interface.
>
> Let's move it to virtio_ring.c
>
> Cc: Tiwei Bie <tiwei.bie@intel.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/virtio/virtio_ring.c | 7 ++++++-
> include/uapi/linux/virtio_ring.h | 10 ----------
> 2 files changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index 412e0c431d87..1c85b3423182 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -152,7 +152,12 @@ struct vring_virtqueue {
> /* Available for packed ring */
> struct {
> /* Actual memory layout for this queue. */
> - struct vring_packed vring;
> + struct {
> + unsigned int num;
> + struct vring_packed_desc *desc;
> + struct vring_packed_desc_event *driver;
> + struct vring_packed_desc_event *device;
> + } vring;
>
> /* Driver ring wrap counter. */
> bool avail_wrap_counter;
> diff --git a/include/uapi/linux/virtio_ring.h b/include/uapi/linux/virtio_ring.h
> index 2414f8af26b3..4c4e24c291a5 100644
> --- a/include/uapi/linux/virtio_ring.h
> +++ b/include/uapi/linux/virtio_ring.h
> @@ -213,14 +213,4 @@ struct vring_packed_desc {
> __le16 flags;
> };
>
> -struct vring_packed {
> - unsigned int num;
> -
> - struct vring_packed_desc *desc;
> -
> - struct vring_packed_desc_event *driver;
> -
> - struct vring_packed_desc_event *device;
> -};
> -
> #endif /* _UAPI_LINUX_VIRTIO_RING_H */
Acked-by: Jason Wang <jasowang@redhat.com>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] virtio: drop internal struct from UAPI
From: Tiwei Bie @ 2019-02-02 4:04 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: linux-kernel, virtualization
In-Reply-To: <20190201221553.7210-1-mst@redhat.com>
On Fri, Feb 01, 2019 at 05:16:01PM -0500, Michael S. Tsirkin wrote:
> There's no reason to expose struct vring_packed in UAPI - if we do we
> won't be able to change or drop it, and it's not part of any interface.
>
> Let's move it to virtio_ring.c
>
> Cc: Tiwei Bie <tiwei.bie@intel.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/virtio/virtio_ring.c | 7 ++++++-
> include/uapi/linux/virtio_ring.h | 10 ----------
> 2 files changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index 412e0c431d87..1c85b3423182 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -152,7 +152,12 @@ struct vring_virtqueue {
> /* Available for packed ring */
> struct {
> /* Actual memory layout for this queue. */
> - struct vring_packed vring;
> + struct {
> + unsigned int num;
> + struct vring_packed_desc *desc;
> + struct vring_packed_desc_event *driver;
> + struct vring_packed_desc_event *device;
> + } vring;
>
> /* Driver ring wrap counter. */
> bool avail_wrap_counter;
> diff --git a/include/uapi/linux/virtio_ring.h b/include/uapi/linux/virtio_ring.h
> index 2414f8af26b3..4c4e24c291a5 100644
> --- a/include/uapi/linux/virtio_ring.h
> +++ b/include/uapi/linux/virtio_ring.h
> @@ -213,14 +213,4 @@ struct vring_packed_desc {
> __le16 flags;
> };
>
> -struct vring_packed {
> - unsigned int num;
> -
> - struct vring_packed_desc *desc;
> -
> - struct vring_packed_desc_event *driver;
> -
> - struct vring_packed_desc_event *device;
> -};
> -
> #endif /* _UAPI_LINUX_VIRTIO_RING_H */
> --
> MST
Acked-by: Tiwei Bie <tiwei.bie@intel.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox