This small series enables virtio-net device type in VDUSE.
With it, basic operation have been tested, both with
virtio-vdpa and vhost-vdpa using DPDK Vhost library series
adding VDUSE support using split rings layout (merged in
DPDK v23.07-rc1).
Control queue support (and so multiqueue) has also been
tested, but requires a Kernel series from Jason Wang
relaxing control queue polling [1] to function reliably,
so while Jason rework is done, a patch is added to fail init
if control queue feature is requested.(tested also with DPDK
v23.11).
Changes in v7:
==============
- Fail init only if VIRTIO_NET_F_CTRL_VQ is requested.
- Convert to use BIT_ULL() macro
- Rebased
Changes in v6:
==============
- Remove SELinux support from the series, will be handled
in a dedicated one.
- Require CAP_NET_ADMIN for Net devices creation (Jason).
- Fail init if control queue features are requested for
Net device type (Jason).
- Rebased on latest master.
Changes in v5:
==============
- Move control queue disablement patch before Net
devices enablement (Jason).
- Unify operations LSM hooks into a single hook.
- Rebase on latest master.
Maxime Coquelin (3):
vduse: validate block features only with block devices
vduse: Temporarily fail if control queue feature requested
vduse: enable Virtio-net device type
drivers/vdpa/vdpa_user/vduse_dev.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
--
2.43.0
Virtio-net driver control queue implementation is not safe
when used with VDUSE. If the VDUSE application does not
reply to control queue messages, it currently ends up
hanging the kernel thread sending this command.
Some work is on-going to make the control queue
implementation robust with VDUSE. Until it is completed,
let's fail features check if control-queue feature is
requested.
Signed-off-by: Maxime Coquelin <[email protected]>
---
drivers/vdpa/vdpa_user/vduse_dev.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
index a5af6d4077b8..00f3f562ab5d 100644
--- a/drivers/vdpa/vdpa_user/vduse_dev.c
+++ b/drivers/vdpa/vdpa_user/vduse_dev.c
@@ -8,6 +8,7 @@
*
*/
+#include "linux/virtio_net.h"
#include <linux/init.h>
#include <linux/module.h>
#include <linux/cdev.h>
@@ -28,6 +29,7 @@
#include <uapi/linux/virtio_config.h>
#include <uapi/linux/virtio_ids.h>
#include <uapi/linux/virtio_blk.h>
+#include <uapi/linux/virtio_ring.h>
#include <linux/mod_devicetable.h>
#include "iova_domain.h"
@@ -1680,6 +1682,9 @@ static bool features_is_valid(struct vduse_dev_config *config)
if ((config->device_id == VIRTIO_ID_BLOCK) &&
(config->features & BIT_ULL(VIRTIO_BLK_F_CONFIG_WCE)))
return false;
+ else if ((config->device_id == VIRTIO_ID_NET) &&
+ (config->features & BIT_ULL(VIRTIO_NET_F_CTRL_VQ)))
+ return false;
return true;
}
--
2.43.0
This patch is preliminary work to enable network device
type support to VDUSE.
As VIRTIO_BLK_F_CONFIG_WCE shares the same value as
VIRTIO_NET_F_HOST_TSO4, we need to restrict its check
to Virtio-blk device type.
Acked-by: Jason Wang <[email protected]>
Reviewed-by: Xie Yongji <[email protected]>
Reviewed-by: Eugenio Pérez <[email protected]>
Signed-off-by: Maxime Coquelin <[email protected]>
---
drivers/vdpa/vdpa_user/vduse_dev.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
index 0ddd4b8abecb..a5af6d4077b8 100644
--- a/drivers/vdpa/vdpa_user/vduse_dev.c
+++ b/drivers/vdpa/vdpa_user/vduse_dev.c
@@ -1671,13 +1671,14 @@ static bool device_is_allowed(u32 device_id)
return false;
}
-static bool features_is_valid(u64 features)
+static bool features_is_valid(struct vduse_dev_config *config)
{
- if (!(features & (1ULL << VIRTIO_F_ACCESS_PLATFORM)))
+ if (!(config->features & BIT_ULL(VIRTIO_F_ACCESS_PLATFORM)))
return false;
/* Now we only support read-only configuration space */
- if (features & (1ULL << VIRTIO_BLK_F_CONFIG_WCE))
+ if ((config->device_id == VIRTIO_ID_BLOCK) &&
+ (config->features & BIT_ULL(VIRTIO_BLK_F_CONFIG_WCE)))
return false;
return true;
@@ -1704,7 +1705,7 @@ static bool vduse_validate_config(struct vduse_dev_config *config)
if (!device_is_allowed(config->device_id))
return false;
- if (!features_is_valid(config->features))
+ if (!features_is_valid(config))
return false;
return true;
--
2.43.0
This patch adds Virtio-net device type to the supported
devices types.
Initialization fails if the device does not support
VIRTIO_F_VERSION_1 feature, in order to guarantee the
configuration space is read-only. It also fails with
-EPERM if the CAP_NET_ADMIN is missing.
Acked-by: Jason Wang <[email protected]>
Reviewed-by: Eugenio Pérez <[email protected]>
Signed-off-by: Maxime Coquelin <[email protected]>
---
drivers/vdpa/vdpa_user/vduse_dev.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
index 00f3f562ab5d..8924bbc55635 100644
--- a/drivers/vdpa/vdpa_user/vduse_dev.c
+++ b/drivers/vdpa/vdpa_user/vduse_dev.c
@@ -143,6 +143,7 @@ static struct workqueue_struct *vduse_irq_bound_wq;
static u32 allowed_device_id[] = {
VIRTIO_ID_BLOCK,
+ VIRTIO_ID_NET,
};
static inline struct vduse_dev *vdpa_to_vduse(struct vdpa_device *vdpa)
@@ -1686,6 +1687,10 @@ static bool features_is_valid(struct vduse_dev_config *config)
(config->features & BIT_ULL(VIRTIO_NET_F_CTRL_VQ)))
return false;
+ if ((config->device_id == VIRTIO_ID_NET) &&
+ !(config->features & BIT_ULL(VIRTIO_F_VERSION_1)))
+ return false;
+
return true;
}
@@ -1793,6 +1798,10 @@ static int vduse_create_dev(struct vduse_dev_config *config,
int ret;
struct vduse_dev *dev;
+ ret = -EPERM;
+ if ((config->device_id == VIRTIO_ID_NET) && !capable(CAP_NET_ADMIN))
+ goto err;
+
ret = -EEXIST;
if (vduse_find_dev(config->name))
goto err;
@@ -2036,6 +2045,7 @@ static const struct vdpa_mgmtdev_ops vdpa_dev_mgmtdev_ops = {
static struct virtio_device_id id_table[] = {
{ VIRTIO_ID_BLOCK, VIRTIO_DEV_ANY_ID },
+ { VIRTIO_ID_NET, VIRTIO_DEV_ANY_ID },
{ 0 },
};
--
2.43.0
On Tue, Jan 9, 2024 at 12:11 PM Maxime Coquelin
<[email protected]> wrote:
>
> Virtio-net driver control queue implementation is not safe
> when used with VDUSE. If the VDUSE application does not
> reply to control queue messages, it currently ends up
> hanging the kernel thread sending this command.
>
> Some work is on-going to make the control queue
> implementation robust with VDUSE. Until it is completed,
> let's fail features check if control-queue feature is
> requested.
>
> Signed-off-by: Maxime Coquelin <[email protected]>
Acked-by: Eugenio Pérez <[email protected]>
Thanks!
> ---
> drivers/vdpa/vdpa_user/vduse_dev.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
> index a5af6d4077b8..00f3f562ab5d 100644
> --- a/drivers/vdpa/vdpa_user/vduse_dev.c
> +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> @@ -8,6 +8,7 @@
> *
> */
>
> +#include "linux/virtio_net.h"
> #include <linux/init.h>
> #include <linux/module.h>
> #include <linux/cdev.h>
> @@ -28,6 +29,7 @@
> #include <uapi/linux/virtio_config.h>
> #include <uapi/linux/virtio_ids.h>
> #include <uapi/linux/virtio_blk.h>
> +#include <uapi/linux/virtio_ring.h>
> #include <linux/mod_devicetable.h>
>
> #include "iova_domain.h"
> @@ -1680,6 +1682,9 @@ static bool features_is_valid(struct vduse_dev_config *config)
> if ((config->device_id == VIRTIO_ID_BLOCK) &&
> (config->features & BIT_ULL(VIRTIO_BLK_F_CONFIG_WCE)))
> return false;
> + else if ((config->device_id == VIRTIO_ID_NET) &&
> + (config->features & BIT_ULL(VIRTIO_NET_F_CTRL_VQ)))
> + return false;
>
> return true;
> }
> --
> 2.43.0
>
>
On Tue, Jan 9, 2024 at 7:10 PM Maxime Coquelin
<[email protected]> wrote:
>
> Virtio-net driver control queue implementation is not safe
> when used with VDUSE. If the VDUSE application does not
> reply to control queue messages, it currently ends up
> hanging the kernel thread sending this command.
>
> Some work is on-going to make the control queue
> implementation robust with VDUSE. Until it is completed,
> let's fail features check if control-queue feature is
> requested.
>
> Signed-off-by: Maxime Coquelin <[email protected]>
Reviewed-by: Xie Yongji <[email protected]>
Thanks,
Yongji
> ---
> drivers/vdpa/vdpa_user/vduse_dev.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
> index a5af6d4077b8..00f3f562ab5d 100644
> --- a/drivers/vdpa/vdpa_user/vduse_dev.c
> +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> @@ -8,6 +8,7 @@
> *
> */
>
> +#include "linux/virtio_net.h"
> #include <linux/init.h>
> #include <linux/module.h>
> #include <linux/cdev.h>
> @@ -28,6 +29,7 @@
> #include <uapi/linux/virtio_config.h>
> #include <uapi/linux/virtio_ids.h>
> #include <uapi/linux/virtio_blk.h>
> +#include <uapi/linux/virtio_ring.h>
> #include <linux/mod_devicetable.h>
>
> #include "iova_domain.h"
> @@ -1680,6 +1682,9 @@ static bool features_is_valid(struct vduse_dev_config *config)
> if ((config->device_id == VIRTIO_ID_BLOCK) &&
> (config->features & BIT_ULL(VIRTIO_BLK_F_CONFIG_WCE)))
> return false;
> + else if ((config->device_id == VIRTIO_ID_NET) &&
> + (config->features & BIT_ULL(VIRTIO_NET_F_CTRL_VQ)))
> + return false;
>
> return true;
> }
> --
> 2.43.0
>
On Tue, Jan 9, 2024 at 7:10 PM Maxime Coquelin
<[email protected]> wrote:
>
> This patch adds Virtio-net device type to the supported
> devices types.
>
> Initialization fails if the device does not support
> VIRTIO_F_VERSION_1 feature, in order to guarantee the
> configuration space is read-only. It also fails with
> -EPERM if the CAP_NET_ADMIN is missing.
>
> Acked-by: Jason Wang <[email protected]>
> Reviewed-by: Eugenio Pérez <[email protected]>
> Signed-off-by: Maxime Coquelin <[email protected]>
Reviewed-by: Xie Yongji <[email protected]>
Thanks,
Yongji
> ---
> drivers/vdpa/vdpa_user/vduse_dev.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
> index 00f3f562ab5d..8924bbc55635 100644
> --- a/drivers/vdpa/vdpa_user/vduse_dev.c
> +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> @@ -143,6 +143,7 @@ static struct workqueue_struct *vduse_irq_bound_wq;
>
> static u32 allowed_device_id[] = {
> VIRTIO_ID_BLOCK,
> + VIRTIO_ID_NET,
> };
>
> static inline struct vduse_dev *vdpa_to_vduse(struct vdpa_device *vdpa)
> @@ -1686,6 +1687,10 @@ static bool features_is_valid(struct vduse_dev_config *config)
> (config->features & BIT_ULL(VIRTIO_NET_F_CTRL_VQ)))
> return false;
>
> + if ((config->device_id == VIRTIO_ID_NET) &&
> + !(config->features & BIT_ULL(VIRTIO_F_VERSION_1)))
> + return false;
> +
> return true;
> }
>
> @@ -1793,6 +1798,10 @@ static int vduse_create_dev(struct vduse_dev_config *config,
> int ret;
> struct vduse_dev *dev;
>
> + ret = -EPERM;
> + if ((config->device_id == VIRTIO_ID_NET) && !capable(CAP_NET_ADMIN))
> + goto err;
> +
> ret = -EEXIST;
> if (vduse_find_dev(config->name))
> goto err;
> @@ -2036,6 +2045,7 @@ static const struct vdpa_mgmtdev_ops vdpa_dev_mgmtdev_ops = {
>
> static struct virtio_device_id id_table[] = {
> { VIRTIO_ID_BLOCK, VIRTIO_DEV_ANY_ID },
> + { VIRTIO_ID_NET, VIRTIO_DEV_ANY_ID },
> { 0 },
> };
>
> --
> 2.43.0
>
On Tue, Jan 9, 2024 at 7:10 PM Maxime Coquelin
<[email protected]> wrote:
>
> Virtio-net driver control queue implementation is not safe
> when used with VDUSE. If the VDUSE application does not
> reply to control queue messages, it currently ends up
> hanging the kernel thread sending this command.
>
> Some work is on-going to make the control queue
> implementation robust with VDUSE. Until it is completed,
> let's fail features check if control-queue feature is
> requested.
>
> Signed-off-by: Maxime Coquelin <[email protected]>
Acked-by: Jason Wang <[email protected]>
Thanks
> ---
> drivers/vdpa/vdpa_user/vduse_dev.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
> index a5af6d4077b8..00f3f562ab5d 100644
> --- a/drivers/vdpa/vdpa_user/vduse_dev.c
> +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> @@ -8,6 +8,7 @@
> *
> */
>
> +#include "linux/virtio_net.h"
> #include <linux/init.h>
> #include <linux/module.h>
> #include <linux/cdev.h>
> @@ -28,6 +29,7 @@
> #include <uapi/linux/virtio_config.h>
> #include <uapi/linux/virtio_ids.h>
> #include <uapi/linux/virtio_blk.h>
> +#include <uapi/linux/virtio_ring.h>
> #include <linux/mod_devicetable.h>
>
> #include "iova_domain.h"
> @@ -1680,6 +1682,9 @@ static bool features_is_valid(struct vduse_dev_config *config)
> if ((config->device_id == VIRTIO_ID_BLOCK) &&
> (config->features & BIT_ULL(VIRTIO_BLK_F_CONFIG_WCE)))
> return false;
> + else if ((config->device_id == VIRTIO_ID_NET) &&
> + (config->features & BIT_ULL(VIRTIO_NET_F_CTRL_VQ)))
> + return false;
>
> return true;
> }
> --
> 2.43.0
>
Hi Jason,
It looks like all patches got acked by you.
Any blocker to queue the series for next release?
Thanks,
Maxime
On 1/9/24 12:10, Maxime Coquelin wrote:
> This small series enables virtio-net device type in VDUSE.
> With it, basic operation have been tested, both with
> virtio-vdpa and vhost-vdpa using DPDK Vhost library series
> adding VDUSE support using split rings layout (merged in
> DPDK v23.07-rc1).
>
> Control queue support (and so multiqueue) has also been
> tested, but requires a Kernel series from Jason Wang
> relaxing control queue polling [1] to function reliably,
> so while Jason rework is done, a patch is added to fail init
> if control queue feature is requested.(tested also with DPDK
> v23.11).
>
>
> Changes in v7:
> ==============
> - Fail init only if VIRTIO_NET_F_CTRL_VQ is requested.
> - Convert to use BIT_ULL() macro
> - Rebased
>
> Changes in v6:
> ==============
> - Remove SELinux support from the series, will be handled
> in a dedicated one.
> - Require CAP_NET_ADMIN for Net devices creation (Jason).
> - Fail init if control queue features are requested for
> Net device type (Jason).
> - Rebased on latest master.
>
> Changes in v5:
> ==============
> - Move control queue disablement patch before Net
> devices enablement (Jason).
> - Unify operations LSM hooks into a single hook.
> - Rebase on latest master.
>
> Maxime Coquelin (3):
> vduse: validate block features only with block devices
> vduse: Temporarily fail if control queue feature requested
> vduse: enable Virtio-net device type
>
> drivers/vdpa/vdpa_user/vduse_dev.c | 24 ++++++++++++++++++++----
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
On Thu, Feb 01, 2024 at 09:34:11AM +0100, Maxime Coquelin wrote:
> Hi Jason,
>
> It looks like all patches got acked by you.
> Any blocker to queue the series for next release?
>
> Thanks,
> Maxime
I think it's good enough at this point. Will put it in
linux-next shortly.
On 2/1/24 09:40, Michael S. Tsirkin wrote:
> On Thu, Feb 01, 2024 at 09:34:11AM +0100, Maxime Coquelin wrote:
>> Hi Jason,
>>
>> It looks like all patches got acked by you.
>> Any blocker to queue the series for next release?
>>
>> Thanks,
>> Maxime
>
> I think it's good enough at this point. Will put it in
> linux-next shortly.
>
Thanks Michael!
Hello Michael,
On 2/1/24 09:40, Michael S. Tsirkin wrote:
> On Thu, Feb 01, 2024 at 09:34:11AM +0100, Maxime Coquelin wrote:
>> Hi Jason,
>>
>> It looks like all patches got acked by you.
>> Any blocker to queue the series for next release?
>>
>> Thanks,
>> Maxime
>
> I think it's good enough at this point. Will put it in
> linux-next shortly.
>
I fetched linux-next and it seems the series is not in yet.
Is there anything to be reworked on my side?
Thanks,
Maxime
On Thu, Feb 29, 2024 at 11:16:04AM +0100, Maxime Coquelin wrote:
> Hello Michael,
>
> On 2/1/24 09:40, Michael S. Tsirkin wrote:
> > On Thu, Feb 01, 2024 at 09:34:11AM +0100, Maxime Coquelin wrote:
> > > Hi Jason,
> > >
> > > It looks like all patches got acked by you.
> > > Any blocker to queue the series for next release?
> > >
> > > Thanks,
> > > Maxime
> >
> > I think it's good enough at this point. Will put it in
> > linux-next shortly.
> >
>
> I fetched linux-next and it seems the series is not in yet.
> Is there anything to be reworked on my side?
>
> Thanks,
> Maxime
I am sorry I messed up. It was in a wrong branch and was not
pushed so of course it did not get tested and I kept wondering
why. I pushed it in my tree but it is too late to put it upstream
for this cycle. Assuming Linus merges my tree
with no drama, I will make an effort not to rebase my tree below them
so these patches will keep their hashes, you can use them already.
--
MST