[PATCH 1/2] MAINTAINERS: add a dedicated entry for vDPA
vDPA is an independent subsystem, so use a dedicated entry for that. Signed-off-by: Jason Wang --- MAINTAINERS | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 4e2698cc7e23..314398f0e276 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -18173,13 +18173,19 @@ F:Documentation/devicetree/bindings/virtio/ F: drivers/block/virtio_blk.c F: drivers/crypto/virtio/ F: drivers/net/virtio_net.c -F: drivers/vdpa/ F: drivers/virtio/ -F: include/linux/vdpa.h F: include/linux/virtio*.h F: include/uapi/linux/virtio_*.h F: tools/virtio/ +VDPA CORE AND DRIVERS +M: "Michael S. Tsirkin" +M: Jason Wang +L: virtualization@lists.linux-foundation.org +S: Maintained +F: drivers/vdpa/ +F: include/linux/vdpa.h + VIRTIO BALLOON M: "Michael S. Tsirkin" M: David Hildenbrand -- 2.20.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH 2/2] vDPA: add Eli Cohen as mellanox vDPA driver supporter
Cc: Eli Cohen Signed-off-by: Jason Wang --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 314398f0e276..ed1851413fcc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -18186,6 +18186,12 @@ S: Maintained F: drivers/vdpa/ F: include/linux/vdpa.h +MELLANOX VDPA DRIVERS +M: Eli Cohen +L: virtualization@lists.linux-foundation.org +S: Supported +F: drivers/vdpa/mlx5/ + VIRTIO BALLOON M: "Michael S. Tsirkin" M: David Hildenbrand -- 2.20.1 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] vdpa_sim: init iommu lock
On 2020/8/10 下午8:48, Michael S. Tsirkin wrote:
The patch adding the iommu lock did not initialize it.
The struct is zero-initialized so this is mostly a problem
when using lockdep.
Reported-by: kernel test robot
Cc: Max Gurtovoy
Fixes: 0ea9ee430e74 ("vdpasim: protect concurrent access to iommu iotlb")
Signed-off-by: Michael S. Tsirkin
Acked-by: Jason Wang
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index df3224b138ee..604d9d25ca47 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -358,6 +358,7 @@ static struct vdpasim *vdpasim_create(void)
INIT_WORK(>work, vdpasim_work);
spin_lock_init(>lock);
+ spin_lock_init(>iommu_lock);
dev = >vdpa.dev;
dev->coherent_dma_mask = DMA_BIT_MASK(64);
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH V5 1/6] vhost: introduce vhost_vring_call
On 2020/8/10 下午9:37, Michael S. Tsirkin wrote:
On Wed, Aug 05, 2020 at 10:16:16AM +0800, Jason Wang wrote:
On 2020/8/4 下午5:21, Michael S. Tsirkin wrote:
+struct vhost_vring_call {
+ struct eventfd_ctx *ctx;
+ struct irq_bypass_producer producer;
+ spinlock_t ctx_lock;
It's not clear to me why we need ctx_lock here.
Thanks
Hi Jason,
we use this lock to protect the eventfd_ctx and irq from race conditions,
We don't support irq notification from vDPA device driver in this version,
do we still have race condition?
Thanks
Jason I'm not sure what you are trying to say here.
I meant we change the API from V4 so driver won't notify us if irq is
changed.
Then it looks to me there's no need for the ctx_lock, everyhing could be
synchronized with vq mutex.
Thanks
Jason do you want to post a cleanup patch simplifying code along these
lines?
Ling Shan promised to post a patch to fix this.
Thanks
Thanks,
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 1/4] vdpa: introduce config op to get valid iova range
On 2020/8/10 下午8:05, Michael S. Tsirkin wrote:
On Thu, Aug 06, 2020 at 03:43:54PM +0300, Eli Cohen wrote:
On Thu, Aug 06, 2020 at 08:29:22AM -0400, Michael S. Tsirkin wrote:
On Thu, Aug 06, 2020 at 03:03:55PM +0300, Eli Cohen wrote:
On Wed, Aug 05, 2020 at 08:51:56AM -0400, Michael S. Tsirkin wrote:
On Wed, Jun 17, 2020 at 11:29:44AM +0800, Jason Wang wrote:
This patch introduce a config op to get valid iova range from the vDPA
device.
Signed-off-by: Jason Wang
---
include/linux/vdpa.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index 239db794357c..b7633ed2500c 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -41,6 +41,16 @@ struct vdpa_device {
unsigned int index;
};
+/**
+ * vDPA IOVA range - the IOVA range support by the device
+ * @start: start of the IOVA range
+ * @end: end of the IOVA range
+ */
+struct vdpa_iova_range {
+ u64 start;
+ u64 end;
+};
+
This is ambiguous. Is end in the range or just behind it?
How about first/last?
It is customary in the kernel to use start-end where end corresponds to
the byte following the last in the range. See struct vm_area_struct
vm_start and vm_end fields
Exactly my point:
include/linux/mm_types.h: unsigned long vm_end; /* The first
byte after our end address
in this case Jason wants it to be the last byte, not one behind.
Maybe start, size? Not ambiguous, and you don't need to do annoying
calculations like size = last - start + 1
Size has a bunch of issues: can overlap, can not cover the entire 64 bit
range. The requisite checks are arguably easier to get wrong than
getting the size if you need it.
Yes, so do you still prefer first/last or just begin/end which is
consistent with iommu_domain_geometry?
Thanks
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 0/6] mm / virtio-mem: support ZONE_MOVABLE
On Mon, 10 Aug 2020 09:56:32 +0200 David Hildenbrand wrote: > On 04.08.20 21:41, David Hildenbrand wrote: > > @Andrew can we give this a churn and consider it for v5.9 in case there > > are no more comments? > > @Andrew, Ping, so I assume we'll target v5.10? Yep, sorry. Merging a significant patch series during the merge window(!) would be quite extraordinary and I don't think that anything in this patchset justifies such an action? ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 4/7] x86/paravirt: remove 32-bit support from PARAVIRT_XXL
On 10.08.20 18:53, Boris Ostrovsky wrote:
On 8/10/20 12:39 AM, Jürgen Groß wrote:
On 09.08.20 04:34, Boris Ostrovsky wrote:
On 8/7/20 4:38 AM, Juergen Gross wrote:
@@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val)
{
pteval_t ret;
- if (sizeof(pteval_t) > sizeof(long))
- ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >>
32);
- else
- ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val);
+ ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val);
return (pte_t) { .pte = ret };
Can this now simply return (pte_t) ret?
I don't think so, but I can turn it into
return native_make_pte(PVOP_CALLEE1(...));
I thought that since now this is only built for 64-bit we don't have to
worry about different pte_t definitions and can do what we do for
example, for __pgd()?
Yes, I did that:
return (pte_t) { ret };
Juergen
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 4/7] x86/paravirt: remove 32-bit support from PARAVIRT_XXL
On 8/10/20 12:39 AM, Jürgen Groß wrote:
> On 09.08.20 04:34, Boris Ostrovsky wrote:
>> On 8/7/20 4:38 AM, Juergen Gross wrote:
>>> @@ -377,10 +373,7 @@ static inline pte_t __pte(pteval_t val)
>>> {
>>> pteval_t ret;
>>> - if (sizeof(pteval_t) > sizeof(long))
>>> - ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >>
>>> 32);
>>> - else
>>> - ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val);
>>> + ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val);
>>> return (pte_t) { .pte = ret };
>>
>>
>> Can this now simply return (pte_t) ret?
>
> I don't think so, but I can turn it into
>
> return native_make_pte(PVOP_CALLEE1(...));
I thought that since now this is only built for 64-bit we don't have to
worry about different pte_t definitions and can do what we do for
example, for __pgd()?
-boris
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: linux-next: Tree for Aug 10 (drivers/vdpa/mlx5/net)
On 8/9/20 9:10 PM, Stephen Rothwell wrote:
> Hi all,
>
on i386:
Lots (63) of left shift warnings: {not all are shown here}
CC drivers/vdpa/mlx5/net/mlx5_vnet.o
In file included from ../include/linux/bits.h:6:0,
from ../include/linux/bitops.h:5,
from ../include/linux/kernel.h:12,
from ../include/linux/vdpa.h:5,
from ../drivers/vdpa/mlx5/net/mlx5_vnet.c:4:
../drivers/vdpa/mlx5/net/mlx5_vnet.c: In function 'print_features':
../include/vdso/bits.h:7:26: warning: left shift count >= width of type
[-Wshift-count-overflow]
#define BIT(nr) (UL(1) << (nr))
^
../drivers/vdpa/mlx5/net/mlx5_vnet.c:27:60: note: in expansion of macro 'BIT'
BIT(VIRTIO_NET_F_MQ) | BIT(VIRTIO_NET_F_CTRL_MAC_ADDR) |
BIT(VIRTIO_NET_F_HASH_REPORT) | \
^~~
../drivers/vdpa/mlx5/net/mlx5_vnet.c:186:18: note: in expansion of macro
'VALID_FEATURES_MASK'
if (features & ~VALID_FEATURES_MASK)
^~~
../include/vdso/bits.h:7:26: warning: left shift count >= width of type
[-Wshift-count-overflow]
#define BIT(nr) (UL(1) << (nr))
^
../drivers/vdpa/mlx5/net/mlx5_vnet.c:28:3: note: in expansion of macro 'BIT'
BIT(VIRTIO_NET_F_RSS) | BIT(VIRTIO_NET_F_RSC_EXT) |
BIT(VIRTIO_NET_F_STANDBY) | \
^~~
../drivers/vdpa/mlx5/net/mlx5_vnet.c:186:18: note: in expansion of macro
'VALID_FEATURES_MASK'
if (features & ~VALID_FEATURES_MASK)
^~~
../include/vdso/bits.h:7:26: warning: left shift count >= width of type
[-Wshift-count-overflow]
#define BIT(nr) (UL(1) << (nr))
^
../drivers/vdpa/mlx5/net/mlx5_vnet.c:28:27: note: in expansion of macro 'BIT'
BIT(VIRTIO_NET_F_RSS) | BIT(VIRTIO_NET_F_RSC_EXT) |
BIT(VIRTIO_NET_F_STANDBY) | \
^~~
../drivers/vdpa/mlx5/net/mlx5_vnet.c:186:18: note: in expansion of macro
'VALID_FEATURES_MASK'
if (features & ~VALID_FEATURES_MASK)
^~~
../include/vdso/bits.h:7:26: warning: left shift count >= width of type
[-Wshift-count-overflow]
#define BIT(nr) (UL(1) << (nr))
^
../drivers/vdpa/mlx5/net/mlx5_vnet.c:28:55: note: in expansion of macro 'BIT'
BIT(VIRTIO_NET_F_RSS) | BIT(VIRTIO_NET_F_RSC_EXT) |
BIT(VIRTIO_NET_F_STANDBY) | \
^~~
../drivers/vdpa/mlx5/net/mlx5_vnet.c:186:18: note: in expansion of macro
'VALID_FEATURES_MASK'
if (features & ~VALID_FEATURES_MASK)
^~~
../include/vdso/bits.h:7:26: warning: left shift count >= width of type
[-Wshift-count-overflow]
#define BIT(nr) (UL(1) << (nr))
^
../drivers/vdpa/mlx5/net/mlx5_vnet.c:29:3: note: in expansion of macro 'BIT'
BIT(VIRTIO_NET_F_SPEED_DUPLEX) | BIT(VIRTIO_F_NOTIFY_ON_EMPTY) |
\
^~~
../drivers/vdpa/mlx5/net/mlx5_vnet.c:186:18: note: in expansion of macro
'VALID_FEATURES_MASK'
if (features & ~VALID_FEATURES_MASK)
^~~
../include/vdso/bits.h:7:26: warning: left shift count >= width of type
[-Wshift-count-overflow]
#define BIT(nr) (UL(1) << (nr))
^
../drivers/vdpa/mlx5/net/mlx5_vnet.c:30:30: note: in expansion of macro 'BIT'
BIT(VIRTIO_F_ANY_LAYOUT) | BIT(VIRTIO_F_VERSION_1) |
BIT(VIRTIO_F_ACCESS_PLATFORM) | \
^~~
../drivers/vdpa/mlx5/net/mlx5_vnet.c:186:18: note: in expansion of macro
'VALID_FEATURES_MASK'
if (features & ~VALID_FEATURES_MASK)
^~~
--
~Randy
Reported-by: Randy Dunlap
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] vdpa/mlx5: Fix pointer math in mlx5_vdpa_get_config()
On Mon, Aug 10, 2020 at 01:31:47PM +0300, Dan Carpenter wrote: > On Sun, Aug 09, 2020 at 06:34:04AM +, Eli Cohen wrote: > > Acked-by: Eli Cohen > > > > BTW, vdpa_sim has the same bug. > > > > I sent a patch for that on April 6. > > [PATCH 2/2] vdpa: Fix pointer math bug in vdpasim_get_config() > > Jason acked the patch but it wasn't applied. > > regards, > dan carpenter Oh sorry. I'll drop my patch and queue yours then. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 4/4] vhost: add an RPMsg API
On Tue, Aug 04, 2020 at 05:19:17PM +0200, Guennadi Liakhovetski wrote:
> On Tue, Aug 04, 2020 at 10:27:08AM -0400, Michael S. Tsirkin wrote:
> > On Wed, Jul 22, 2020 at 05:09:27PM +0200, Guennadi Liakhovetski wrote:
> > > Linux supports running the RPMsg protocol over the VirtIO transport
> > > protocol, but currently there is only support for VirtIO clients and
> > > no support for a VirtIO server. This patch adds a vhost-based RPMsg
> > > server implementation.
> > >
> > > Signed-off-by: Guennadi Liakhovetski
> > >
> > > ---
> > > drivers/vhost/Kconfig | 7 +
> > > drivers/vhost/Makefile | 3 +
> > > drivers/vhost/rpmsg.c | 375
> > > drivers/vhost/vhost_rpmsg.h | 74 +++
> > > 4 files changed, 459 insertions(+)
> > > create mode 100644 drivers/vhost/rpmsg.c
> > > create mode 100644 drivers/vhost/vhost_rpmsg.h
> > >
> > > diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
> > > index d3688c6afb87..602421bf1d03 100644
> > > --- a/drivers/vhost/Kconfig
> > > +++ b/drivers/vhost/Kconfig
> > > @@ -38,6 +38,13 @@ config VHOST_NET
> > > To compile this driver as a module, choose M here: the module will
> > > be called vhost_net.
> > >
> > > +config VHOST_RPMSG
> > > + tristate
> >
> > So this lacks a description line so it does not appear
> > in menuconfig. How is user supposed to set it?
> > I added a one-line description.
>
> That was on purpose. I don't think there's any value in this API stand-alone,
> so I let users select it as needed. But we can change that too, id desired.
I guess the patches actually selecting this
are separate then?
> > > + depends on VHOST
> >
> > Other drivers select VHOST instead. Any reason not to
> > do it like this here?
>
> I have
>
> + select VHOST
> + select VHOST_RPMSG
>
> in my client driver patch.
Any issues selecting from here so others get it for free?
If this is selected then dependencies are ignored ...
> > > + help
> > > + Vhost RPMsg API allows vhost drivers to communicate with VirtIO
> > > + drivers, using the RPMsg over VirtIO protocol.
> > > +
> >
> > > config VHOST_SCSI
> > > tristate "VHOST_SCSI TCM fabric driver"
> > > depends on TARGET_CORE && EVENTFD
> > > diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
> > > index f3e1897cce85..9cf459d59f97 100644
> > > --- a/drivers/vhost/Makefile
> > > +++ b/drivers/vhost/Makefile
> > > @@ -2,6 +2,9 @@
> > > obj-$(CONFIG_VHOST_NET) += vhost_net.o
> > > vhost_net-y := net.o
> > >
> > > +obj-$(CONFIG_VHOST_RPMSG) += vhost_rpmsg.o
> > > +vhost_rpmsg-y := rpmsg.o
> > > +
> > > obj-$(CONFIG_VHOST_SCSI) += vhost_scsi.o
> > > vhost_scsi-y := scsi.o
> > >
> > > diff --git a/drivers/vhost/rpmsg.c b/drivers/vhost/rpmsg.c
> > > new file mode 100644
> > > index ..d7ab48414224
> > > --- /dev/null
> > > +++ b/drivers/vhost/rpmsg.c
> > > @@ -0,0 +1,375 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Copyright(c) 2020 Intel Corporation. All rights reserved.
> > > + *
> > > + * Author: Guennadi Liakhovetski
> > > + *
> > > + * Vhost RPMsg VirtIO interface. It provides a set of functions to match
> > > the
> > > + * guest side RPMsg VirtIO API, provided by
> > > drivers/rpmsg/virtio_rpmsg_bus.c
> > > + * These functions handle creation of 2 virtual queues, handling of
> > > endpoint
> > > + * addresses, sending a name-space announcement to the guest as well as
> > > any
> > > + * user messages. This API can be used by any vhost driver to handle
> > > RPMsg
> > > + * specific processing.
> > > + * Specific vhost drivers, using this API will use their own VirtIO
> > > device
> > > + * IDs, that should then also be added to the ID table in
> > > virtio_rpmsg_bus.c
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include "vhost.h"
> > > +#include "vhost_rpmsg.h"
> > > +
> > > +/*
> > > + * All virtio-rpmsg virtual queue kicks always come with just one buffer
> > > -
> > > + * either input or output
> > > + */
> > > +static int vhost_rpmsg_get_single(struct vhost_virtqueue *vq)
> > > +{
> > > + struct vhost_rpmsg *vr = container_of(vq->dev, struct vhost_rpmsg, dev);
> > > + unsigned int out, in;
> > > + int head = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov), ,
> > > ,
> > > + NULL, NULL);
> > > + if (head < 0) {
> > > + vq_err(vq, "%s(): error %d getting buffer\n",
> > > +__func__, head);
> > > + return head;
> > > + }
> > > +
> > > + /* Nothing new? */
> > > + if (head == vq->num)
> > > + return head;
> > > +
> > > + if (vq == >vq[VIRTIO_RPMSG_RESPONSE] && (out || in != 1)) {
> >
> > This in != 1 looks like a dependency on a specific message layout.
> > virtio spec says to avoid these. Using iov iters it's not too hard to do
> > ...
>
> This is an RPMsg VirtIO
Re: [PATCH V5 1/6] vhost: introduce vhost_vring_call
On Wed, Aug 05, 2020 at 10:16:16AM +0800, Jason Wang wrote:
>
> On 2020/8/4 下午5:21, Michael S. Tsirkin wrote:
> > > > > > +struct vhost_vring_call {
> > > > > > + struct eventfd_ctx *ctx;
> > > > > > + struct irq_bypass_producer producer;
> > > > > > + spinlock_t ctx_lock;
> > > > > It's not clear to me why we need ctx_lock here.
> > > > >
> > > > > Thanks
> > > > Hi Jason,
> > > >
> > > > we use this lock to protect the eventfd_ctx and irq from race
> > > > conditions,
> > > We don't support irq notification from vDPA device driver in this version,
> > > do we still have race condition?
> > >
> > > Thanks
> > Jason I'm not sure what you are trying to say here.
>
>
> I meant we change the API from V4 so driver won't notify us if irq is
> changed.
>
> Then it looks to me there's no need for the ctx_lock, everyhing could be
> synchronized with vq mutex.
>
> Thanks
Jason do you want to post a cleanup patch simplifying code along these
lines?
Thanks,
> >
> >
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH] vdpa/mlx5: fix up endian-ness for mtu
VDPA mlx5 accesses config space as native endian - this is
wrong since it's a modern device and actually uses LE.
It only supports modern guests so we could punt and
just force LE, but let's use the full virtio APIs since people
tend to copy/paste code, and this is not data path anyway.
Signed-off-by: Michael S. Tsirkin
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index c6b9ec47e51d..9df69d5efe8c 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -137,6 +137,7 @@ struct mlx5_vdpa_net {
struct mlx5_fc *rx_counter;
struct mlx5_flow_handle *rx_rule;
bool setup;
+ u16 mtu;
};
static void free_resources(struct mlx5_vdpa_net *ndev);
@@ -1506,6 +1507,13 @@ static void teardown_virtqueues(struct mlx5_vdpa_net
*ndev)
}
}
+/* TODO: cross-endian support */
+static inline bool mlx5_vdpa_is_little_endian(struct mlx5_vdpa_dev *mvdev)
+{
+ return virtio_legacy_is_little_endian() ||
+ (mvdev->actual_features & (1ULL << VIRTIO_F_VERSION_1));
+}
+
static int mlx5_vdpa_set_features(struct vdpa_device *vdev, u64 features)
{
struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
@@ -1519,6 +1527,8 @@ static int mlx5_vdpa_set_features(struct vdpa_device
*vdev, u64 features)
return err;
ndev->mvdev.actual_features = features & ndev->mvdev.mlx_features;
+ ndev->config.mtu = __cpu_to_virtio16(mlx5_vdpa_is_little_endian(mvdev),
+ndev->mtu);
return err;
}
@@ -1925,7 +1935,7 @@ void *mlx5_vdpa_add_dev(struct mlx5_core_dev *mdev)
init_mvqs(ndev);
mutex_init(>reslock);
config = >config;
- err = mlx5_query_nic_vport_mtu(mdev, >mtu);
+ err = mlx5_query_nic_vport_mtu(mdev, >mtu);
if (err)
goto err_mtu;
--
MST
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v2 00/20] virtiofs: Add DAX support
On Mon, Aug 10, 2020 at 09:29:47AM +0200, Miklos Szeredi wrote: > On Fri, Aug 7, 2020 at 9:55 PM Vivek Goyal wrote: > > > > > Most of the changes are limited to fuse/virtiofs. There are couple > > of changes needed in generic dax infrastructure and couple of changes > > in virtio to be able to access shared memory region. > > So what's the plan for merging the different subsystems? I can take > all that into the fuse tree, but would need ACKs from the respective > maintainers. I am assuming for DAX patches we need ACK from Dan Williams and for virtio patches we need ack from Michael S. Tsirkin. Dan, Michael, can you please review the dax and virtio patches respectively and if there are no concerns, please provide ACK. Or suggest an alternative way of how these patches can be merged. Thanks Vivek ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH] vdpa_sim: fix pointer math in get_config
There is a pointer math bug here: the variable cast is a struct so the
offset is in units of struct size. If "offset" is non-zero this will
copy memory from beyond the end of the array.
fixes: 2c53d0f64c06 ("vdpasim: vDPA device simulator")
Reported-by: Dan Carpenter
Signed-off-by: Michael S. Tsirkin
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 604d9d25ca47..62d640327145 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -558,7 +558,7 @@ static void vdpasim_get_config(struct vdpa_device *vdpa,
unsigned int offset,
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
if (offset + len < sizeof(struct virtio_net_config))
- memcpy(buf, >config + offset, len);
+ memcpy(buf, (u8 *)>config + offset, len);
}
static void vdpasim_set_config(struct vdpa_device *vdpa, unsigned int offset,
--
MST
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH][next] vdpa/mlx5: fix memory allocation failure checks
On Sun, Aug 09, 2020 at 09:03:47AM +0300, Eli Cohen wrote: > On Thu, Aug 06, 2020 at 05:08:28PM +0100, Colin King wrote: > Acked by: Eli Cohen That should be Acked-by: (with a dash). ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH] vdpa_sim: init iommu lock
The patch adding the iommu lock did not initialize it.
The struct is zero-initialized so this is mostly a problem
when using lockdep.
Reported-by: kernel test robot
Cc: Max Gurtovoy
Fixes: 0ea9ee430e74 ("vdpasim: protect concurrent access to iommu iotlb")
Signed-off-by: Michael S. Tsirkin
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index df3224b138ee..604d9d25ca47 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -358,6 +358,7 @@ static struct vdpasim *vdpasim_create(void)
INIT_WORK(>work, vdpasim_work);
spin_lock_init(>lock);
+ spin_lock_init(>iommu_lock);
dev = >vdpa.dev;
dev->coherent_dma_mask = DMA_BIT_MASK(64);
--
MST
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 1/4] vdpa: introduce config op to get valid iova range
On Thu, Aug 06, 2020 at 03:43:54PM +0300, Eli Cohen wrote:
> On Thu, Aug 06, 2020 at 08:29:22AM -0400, Michael S. Tsirkin wrote:
> > On Thu, Aug 06, 2020 at 03:03:55PM +0300, Eli Cohen wrote:
> > > On Wed, Aug 05, 2020 at 08:51:56AM -0400, Michael S. Tsirkin wrote:
> > > > On Wed, Jun 17, 2020 at 11:29:44AM +0800, Jason Wang wrote:
> > > > > This patch introduce a config op to get valid iova range from the vDPA
> > > > > device.
> > > > >
> > > > > Signed-off-by: Jason Wang
> > > > > ---
> > > > > include/linux/vdpa.h | 14 ++
> > > > > 1 file changed, 14 insertions(+)
> > > > >
> > > > > diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
> > > > > index 239db794357c..b7633ed2500c 100644
> > > > > --- a/include/linux/vdpa.h
> > > > > +++ b/include/linux/vdpa.h
> > > > > @@ -41,6 +41,16 @@ struct vdpa_device {
> > > > > unsigned int index;
> > > > > };
> > > > >
> > > > > +/**
> > > > > + * vDPA IOVA range - the IOVA range support by the device
> > > > > + * @start: start of the IOVA range
> > > > > + * @end: end of the IOVA range
> > > > > + */
> > > > > +struct vdpa_iova_range {
> > > > > + u64 start;
> > > > > + u64 end;
> > > > > +};
> > > > > +
> > > >
> > > >
> > > > This is ambiguous. Is end in the range or just behind it?
> > > > How about first/last?
> > >
> > > It is customary in the kernel to use start-end where end corresponds to
> > > the byte following the last in the range. See struct vm_area_struct
> > > vm_start and vm_end fields
> >
> > Exactly my point:
> >
> > include/linux/mm_types.h: unsigned long vm_end; /* The
> > first byte after our end address
> >
> > in this case Jason wants it to be the last byte, not one behind.
> >
> >
> Maybe start, size? Not ambiguous, and you don't need to do annoying
> calculations like size = last - start + 1
Size has a bunch of issues: can overlap, can not cover the entire 64 bit
range. The requisite checks are arguably easier to get wrong than
getting the size if you need it.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] vdpa/mlx5: Fix pointer math in mlx5_vdpa_get_config()
On Sun, Aug 09, 2020 at 06:34:04AM +, Eli Cohen wrote: > Acked-by: Eli Cohen > > BTW, vdpa_sim has the same bug. > I sent a patch for that on April 6. [PATCH 2/2] vdpa: Fix pointer math bug in vdpasim_get_config() Jason acked the patch but it wasn't applied. regards, dan carpenter ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v3 35/38] virtio_mem: convert to LE accessors
On 05.08.20 15:44, Michael S. Tsirkin wrote: > Virtio mem is modern-only. Use LE accessors for config space. > > Signed-off-by: Michael S. Tsirkin > --- > drivers/virtio/virtio_mem.c | 30 +++--- > 1 file changed, 15 insertions(+), 15 deletions(-) > > diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c > index f26f5f64ae82..c08512fcea90 100644 > --- a/drivers/virtio/virtio_mem.c > +++ b/drivers/virtio/virtio_mem.c > @@ -1530,21 +1530,21 @@ static void virtio_mem_refresh_config(struct > virtio_mem *vm) > uint64_t new_plugged_size, usable_region_size, end_addr; > > /* the plugged_size is just a reflection of what _we_ did previously */ > - virtio_cread(vm->vdev, struct virtio_mem_config, plugged_size, > - _plugged_size); > + virtio_cread_le(vm->vdev, struct virtio_mem_config, plugged_size, > + _plugged_size); > if (WARN_ON_ONCE(new_plugged_size != vm->plugged_size)) > vm->plugged_size = new_plugged_size; > > /* calculate the last usable memory block id */ > - virtio_cread(vm->vdev, struct virtio_mem_config, > - usable_region_size, _region_size); > + virtio_cread_le(vm->vdev, struct virtio_mem_config, > + usable_region_size, _region_size); > end_addr = vm->addr + usable_region_size; > end_addr = min(end_addr, phys_limit); > vm->last_usable_mb_id = virtio_mem_phys_to_mb_id(end_addr) - 1; > > /* see if there is a request to change the size */ > - virtio_cread(vm->vdev, struct virtio_mem_config, requested_size, > - >requested_size); > + virtio_cread_le(vm->vdev, struct virtio_mem_config, requested_size, > + >requested_size); > > dev_info(>vdev->dev, "plugged size: 0x%llx", vm->plugged_size); > dev_info(>vdev->dev, "requested size: 0x%llx", vm->requested_size); > @@ -1677,16 +1677,16 @@ static int virtio_mem_init(struct virtio_mem *vm) > } > > /* Fetch all properties that can't change. */ > - virtio_cread(vm->vdev, struct virtio_mem_config, plugged_size, > - >plugged_size); > - virtio_cread(vm->vdev, struct virtio_mem_config, block_size, > - >device_block_size); > - virtio_cread(vm->vdev, struct virtio_mem_config, node_id, > - _id); > + virtio_cread_le(vm->vdev, struct virtio_mem_config, plugged_size, > + >plugged_size); > + virtio_cread_le(vm->vdev, struct virtio_mem_config, block_size, > + >device_block_size); > + virtio_cread_le(vm->vdev, struct virtio_mem_config, node_id, > + _id); > vm->nid = virtio_mem_translate_node_id(vm, node_id); > - virtio_cread(vm->vdev, struct virtio_mem_config, addr, >addr); > - virtio_cread(vm->vdev, struct virtio_mem_config, region_size, > - >region_size); > + virtio_cread_le(vm->vdev, struct virtio_mem_config, addr, >addr); > + virtio_cread_le(vm->vdev, struct virtio_mem_config, region_size, > + >region_size); > > /* >* We always hotplug memory in memory block granularity. This way, > Acked-by: David Hildenbrand -- Thanks, David / dhildenb ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4 0/6] mm / virtio-mem: support ZONE_MOVABLE
On 04.08.20 21:41, David Hildenbrand wrote: > @Andrew can we give this a churn and consider it for v5.9 in case there > are no more comments? @Andrew, Ping, so I assume we'll target v5.10? > > Patch #1-#4,#6 have RBss or ACKs, patch #5 is virtio-mem stuff maintained > by me (and MST is aware). > > --- > > When introducing virtio-mem, the semantics of ZONE_MOVABLE were rather > unclear, which is why we special-cased ZONE_MOVABLE such that partially > plugged blocks would never end up in ZONE_MOVABLE. > > Now that the semantics are much clearer (and are documented in patch #6), > let's support partially plugged memory blocks in ZONE_MOVABLE, allowing > partially plugged memory blocks to be online to ZONE_MOVABLE and also > unplugging from such memory blocks. This avoids surprises when onlining > of memory blocks suddenly fails, just because they are not completely > populated by virtio-mem (yet). > > This is especially helpful for testing, but also paves the way for > virtio-mem optimizations, allowing more memory to get reliably unplugged. > > Cleanup has_unmovable_pages() and set_migratetype_isolate(), providing > better documentation of how ZONE_MOVABLE interacts with different kind of > unmovable pages (memory offlining vs. alloc_contig_range()). > > v3 -> v4: > - "mm/page_isolation: drop WARN_ON_ONCE() in set_migratetype_isolate()" > -- Fix typo in description > - "virtio-mem: don't special-case ZONE_MOVABLE" > -- Add more details why we initialli special-cased ZONE_MOVABLE (via MST) > - "mm: document semantics of ZONE_MOVABLE" > -- Rephrase some parts of documentation (via Mike) > > v2 -> v3: > - "mm: document semantics of ZONE_MOVABLE" > -- Fix a typo > > v1 -> v2: > - "mm/page_isolation: don't dump_page(NULL) in set_migratetype_isolate()" > -- Move to position 1, add Fixes: tag > -- Drop unused "out:" label > - "mm/page_isolation: drop WARN_ON_ONCE() in set_migratetype_isolate()" > -- Keep curly braces on "else" case > - Replace "[PATCH v1 5/6] mm/page_alloc: restrict ZONE_MOVABLE optimization >in has_unmovable_pages() to memory offlining" > by "mm: document semantics of ZONE_MOVABLE" > -- Brain dump of what I know about ZONE_MOVABLE > > David Hildenbrand (6): > mm/page_isolation: don't dump_page(NULL) in set_migratetype_isolate() > mm/page_alloc: tweak comments in has_unmovable_pages() > mm/page_isolation: drop WARN_ON_ONCE() in set_migratetype_isolate() > mm/page_isolation: cleanup set_migratetype_isolate() > virtio-mem: don't special-case ZONE_MOVABLE > mm: document semantics of ZONE_MOVABLE > > drivers/virtio/virtio_mem.c | 47 +++-- > include/linux/mmzone.h | 35 +++ > mm/page_alloc.c | 22 + > mm/page_isolation.c | 39 ++ > 4 files changed, 66 insertions(+), 77 deletions(-) > -- Thanks, David / dhildenb ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
