[patch net-next 0/6] selftests: virtio_net: introduce initial testing infrastructure

[patch net-next 0/6] selftests: virtio_net: introduce initial testing infrastructure

[Jiri Pirko]

From: Jiri Pirko <jiri@nvidia.com>

This patchset aims at introducing very basic initial infrastructure
for virtio_net testing, namely it focuses on virtio feature testing.

The first patch adds support for debugfs for virtio devices, allowing
user to filter features to pretend to be driver that is not capable
of the filtered feature.

Example:
$cat /sys/bus/virtio/devices/virtio0/features
1110010111111111111101010000110010000000100000000000000000000000
$ echo "5" >/sys/kernel/debug/virtio/virtio0/filter_feature_add
$ cat /sys/kernel/debug/virtio/virtio0/filter_features
5
$ echo "virtio0" > /sys/bus/virtio/drivers/virtio_net/unbind
$ echo "virtio0" > /sys/bus/virtio/drivers/virtio_net/bind
$ cat /sys/bus/virtio/devices/virtio0/features
1110000111111111111101010000110010000000100000000000000000000000

Leverage that in the last patch that lays ground for virtio_net
selftests testing, including very basic F_MAC feature test.

To run this, do:
make -C tools/testing/selftests/ TARGETS=drivers/net/virtio_net/ run_tests

It is assumed, as with lot of other selftests in the net group,
that there are netdevices connected back-to-back. In this case,
two virtio_net devices connected back to back. To configure this loop
on a hypervisor, one may use this script:
#!/bin/bash

DEV1="$1"
DEV2="$2"

sudo tc qdisc add dev $DEV1 clsact
sudo tc qdisc add dev $DEV2 clsact
sudo tc filter add dev $DEV1 ingress protocol all pref 1 matchall action mirred egress redirect dev $DEV2
sudo tc filter add dev $DEV2 ingress protocol all pref 1 matchall action mirred egress redirect dev $DEV1
sudo ip link set $DEV1 up
sudo ip link set $DEV2 up

Jiri Pirko (6):
  virtio: add debugfs infrastructure to allow to debug virtio features
  selftests: forwarding: move couple of initial check to the beginning
  selftests: forwarding: add ability to assemble NETIFS array by driver
    name
  selftests: forwarding: add check_driver() helper
  selftests: forwarding: add wait_for_dev() helper
  selftests: virtio_net: add initial tests

 drivers/virtio/Kconfig                        |   9 ++
 drivers/virtio/Makefile                       |   1 +
 drivers/virtio/virtio.c                       |   8 ++
 drivers/virtio/virtio_debug.c                 | 109 +++++++++++++++
 include/linux/virtio.h                        |  34 +++++
 tools/testing/selftests/Makefile              |   1 +
 .../selftests/drivers/net/virtio_net/Makefile |   5 +
 .../drivers/net/virtio_net/basic_features.sh  | 127 ++++++++++++++++++
 .../net/virtio_net/virtio_net_common.sh       |  99 ++++++++++++++
 tools/testing/selftests/net/forwarding/lib.sh |  88 ++++++++++--
 10 files changed, 472 insertions(+), 9 deletions(-)
 create mode 100644 drivers/virtio/virtio_debug.c
 create mode 100644 tools/testing/selftests/drivers/net/virtio_net/Makefile
 create mode 100755 tools/testing/selftests/drivers/net/virtio_net/basic_features.sh
 create mode 100644 tools/testing/selftests/drivers/net/virtio_net/virtio_net_common.sh

-- 
2.44.0

[patch net-next 1/6] virtio: add debugfs infrastructure to allow to debug virtio features

[Jiri Pirko]

From: Jiri Pirko <jiri@nvidia.com>

Currently there is no way for user to set what features the driver
should obey or not, it is hard wired in the code.

In order to be able to debug the device behavior in case some feature is
disabled, introduce a debugfs infrastructure with couple of files
allowing user to see what features the device advertises and
to set filter for features used by driver.

Example:
$cat /sys/bus/virtio/devices/virtio0/features
1110010111111111111101010000110010000000100000000000000000000000
$ echo "5" >/sys/kernel/debug/virtio/virtio0/filter_feature_add
$ cat /sys/kernel/debug/virtio/virtio0/filter_features
5
$ echo "virtio0" > /sys/bus/virtio/drivers/virtio_net/unbind
$ echo "virtio0" > /sys/bus/virtio/drivers/virtio_net/bind
$ cat /sys/bus/virtio/devices/virtio0/features
1110000111111111111101010000110010000000100000000000000000000000

Note that sysfs "features" know already exists, this patch does not
touch it.

Signed-off-by: Jiri Pirko <jiri@nvidia.com>
---
 drivers/virtio/Kconfig        |   9 +++
 drivers/virtio/Makefile       |   1 +
 drivers/virtio/virtio.c       |   8 +++
 drivers/virtio/virtio_debug.c | 109 ++++++++++++++++++++++++++++++++++
 include/linux/virtio.h        |  34 +++++++++++
 5 files changed, 161 insertions(+)
 create mode 100644 drivers/virtio/virtio_debug.c

diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index c17193544268..fc839a354958 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -178,4 +178,13 @@ config VIRTIO_DMA_SHARED_BUFFER
 	 This option adds a flavor of dma buffers that are backed by
 	 virtio resources.
 
+config VIRTIO_DEBUG
+        bool "Debug facilities"
+        help
+          Enable this to expose debug facilities over debugfs.
+	  This allows to debug features, to see what features the device
+	  advertises and to set filter for features used by driver.
+
+          If unsure, say N.
+
 endif # VIRTIO_MENU
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 73ace62af440..58b2b0489fc9 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
 obj-$(CONFIG_VIRTIO_VDPA) += virtio_vdpa.o
 obj-$(CONFIG_VIRTIO_MEM) += virtio_mem.o
 obj-$(CONFIG_VIRTIO_DMA_SHARED_BUFFER) += virtio_dma_buf.o
+obj-$(CONFIG_VIRTIO_DEBUG) += virtio_debug.o
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index f173587893cb..8d9871145e28 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -274,6 +274,9 @@ static int virtio_dev_probe(struct device *_d)
 	else
 		dev->features = driver_features_legacy & device_features;
 
+	/* When debugging, user may filter some features by hand. */
+	virtio_debug_device_filter_features(dev);
+
 	/* Transport features always preserved to pass to finalize_features. */
 	for (i = VIRTIO_TRANSPORT_F_START; i < VIRTIO_TRANSPORT_F_END; i++)
 		if (device_features & (1ULL << i))
@@ -463,6 +466,8 @@ int register_virtio_device(struct virtio_device *dev)
 	/* Acknowledge that we've seen the device. */
 	virtio_add_status(dev, VIRTIO_CONFIG_S_ACKNOWLEDGE);
 
+	virtio_debug_device_init(dev);
+
 	/*
 	 * device_add() causes the bus infrastructure to look for a matching
 	 * driver.
@@ -494,6 +499,7 @@ void unregister_virtio_device(struct virtio_device *dev)
 	int index = dev->index; /* save for after device release */
 
 	device_unregister(&dev->dev);
+	virtio_debug_device_exit(dev);
 	ida_free(&virtio_index_ida, index);
 }
 EXPORT_SYMBOL_GPL(unregister_virtio_device);
@@ -588,11 +594,13 @@ static int virtio_init(void)
 {
 	if (bus_register(&virtio_bus) != 0)
 		panic("virtio bus registration failed");
+	virtio_debug_init();
 	return 0;
 }
 
 static void __exit virtio_exit(void)
 {
+	virtio_debug_exit();
 	bus_unregister(&virtio_bus);
 	ida_destroy(&virtio_index_ida);
 }
diff --git a/drivers/virtio/virtio_debug.c b/drivers/virtio/virtio_debug.c
new file mode 100644
index 000000000000..28cf30948939
--- /dev/null
+++ b/drivers/virtio/virtio_debug.c
@@ -0,0 +1,109 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include <linux/virtio.h>
+#include <linux/virtio_config.h>
+#include <linux/debugfs.h>
+
+static struct dentry *virtio_debugfs_dir;
+
+static int virtio_debug_device_features_show(struct seq_file *s, void *data)
+{
+	struct virtio_device *dev = s->private;
+	u64 device_features;
+	unsigned int i;
+
+	device_features = dev->config->get_features(dev);
+	for (i = 0; i < BITS_PER_LONG_LONG; i++) {
+		if (device_features & (1ULL << i))
+			seq_printf(s, "%u\n", i);
+	}
+	return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(virtio_debug_device_features);
+
+static int virtio_debug_filter_features_show(struct seq_file *s, void *data)
+{
+	struct virtio_device *dev = s->private;
+	unsigned int i;
+
+	for (i = 0; i < BITS_PER_LONG_LONG; i++) {
+		if (dev->debugfs_filter_features & (1ULL << i))
+			seq_printf(s, "%u\n", i);
+	}
+	return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(virtio_debug_filter_features);
+
+static int virtio_debug_filter_features_clear(void *data, u64 val)
+{
+	struct virtio_device *dev = data;
+
+	if (val == 1)
+		dev->debugfs_filter_features = 0;
+	return 0;
+}
+
+DEFINE_DEBUGFS_ATTRIBUTE(virtio_debug_filter_features_clear_fops, NULL,
+			 virtio_debug_filter_features_clear, "%llu\n");
+
+static int virtio_debug_filter_feature_add(void *data, u64 val)
+{
+	struct virtio_device *dev = data;
+
+	if (val >= BITS_PER_LONG_LONG)
+		return -EINVAL;
+	dev->debugfs_filter_features |= BIT_ULL_MASK(val);
+	return 0;
+}
+
+DEFINE_DEBUGFS_ATTRIBUTE(virtio_debug_filter_feature_add_fops, NULL,
+			 virtio_debug_filter_feature_add, "%llu\n");
+
+static int virtio_debug_filter_feature_del(void *data, u64 val)
+{
+	struct virtio_device *dev = data;
+
+	if (val >= BITS_PER_LONG_LONG)
+		return -EINVAL;
+	dev->debugfs_filter_features &= ~BIT_ULL_MASK(val);
+	return 0;
+}
+
+DEFINE_DEBUGFS_ATTRIBUTE(virtio_debug_filter_feature_del_fops, NULL,
+			 virtio_debug_filter_feature_del, "%llu\n");
+
+void virtio_debug_device_init(struct virtio_device *dev)
+{
+	dev->debugfs_dir = debugfs_create_dir(dev_name(&dev->dev),
+					      virtio_debugfs_dir);
+	debugfs_create_file("device_features", 0400, dev->debugfs_dir, dev,
+			    &virtio_debug_device_features_fops);
+	debugfs_create_file("filter_features", 0400, dev->debugfs_dir, dev,
+			    &virtio_debug_filter_features_fops);
+	debugfs_create_file("filter_features_clear", 0200, dev->debugfs_dir, dev,
+			    &virtio_debug_filter_features_clear_fops);
+	debugfs_create_file("filter_feature_add", 0200, dev->debugfs_dir, dev,
+			    &virtio_debug_filter_feature_add_fops);
+	debugfs_create_file("filter_feature_del", 0200, dev->debugfs_dir, dev,
+			    &virtio_debug_filter_feature_del_fops);
+}
+
+void virtio_debug_device_filter_features(struct virtio_device *dev)
+{
+	dev->features &= ~dev->debugfs_filter_features;
+}
+
+void virtio_debug_device_exit(struct virtio_device *dev)
+{
+	debugfs_remove_recursive(dev->debugfs_dir);
+}
+
+void virtio_debug_init(void)
+{
+	virtio_debugfs_dir = debugfs_create_dir("virtio", NULL);
+}
+
+void virtio_debug_exit(void)
+{
+	debugfs_remove_recursive(virtio_debugfs_dir);
+}
diff --git a/include/linux/virtio.h b/include/linux/virtio.h
index b0201747a263..ab3f36c39686 100644
--- a/include/linux/virtio.h
+++ b/include/linux/virtio.h
@@ -126,6 +126,7 @@ struct virtio_admin_cmd {
  * @vqs: the list of virtqueues for this device.
  * @features: the features supported by both driver and device.
  * @priv: private pointer for the driver's use.
+ * @debugfs_dir: debugfs directory entry.
  */
 struct virtio_device {
 	int index;
@@ -141,6 +142,10 @@ struct virtio_device {
 	struct list_head vqs;
 	u64 features;
 	void *priv;
+#ifdef CONFIG_VIRTIO_DEBUG
+	struct dentry *debugfs_dir;
+	u64 debugfs_filter_features;
+#endif
 };
 
 #define dev_to_virtio(_dev)	container_of_const(_dev, struct virtio_device, dev)
@@ -234,4 +239,33 @@ void virtqueue_dma_sync_single_range_for_cpu(struct virtqueue *_vq, dma_addr_t a
 void virtqueue_dma_sync_single_range_for_device(struct virtqueue *_vq, dma_addr_t addr,
 						unsigned long offset, size_t size,
 						enum dma_data_direction dir);
+
+#ifdef CONFIG_VIRTIO_DEBUG
+void virtio_debug_device_init(struct virtio_device *dev);
+void virtio_debug_device_exit(struct virtio_device *dev);
+void virtio_debug_device_filter_features(struct virtio_device *dev);
+void virtio_debug_init(void);
+void virtio_debug_exit(void);
+#else
+static inline void virtio_debug_device_init(struct virtio_device *dev)
+{
+}
+
+static inline void virtio_debug_device_exit(struct virtio_device *dev)
+{
+}
+
+static inline void virtio_debug_device_filter_features(struct virtio_device *dev)
+{
+}
+
+static inline void virtio_debug_init(void)
+{
+}
+
+static inline void virtio_debug_exit(void)
+{
+}
+#endif
+
 #endif /* _LINUX_VIRTIO_H */
-- 
2.44.0

[patch net-next 2/6] selftests: forwarding: move couple of initial check to the beginning

[Jiri Pirko]

From: Jiri Pirko <jiri@nvidia.com>

These two check can be done at he very beginning of the script.
As the follow up patch needs to add early code that needs to be executed
after the checks, move them.

Signed-off-by: Jiri Pirko <jiri@nvidia.com>
---
 tools/testing/selftests/net/forwarding/lib.sh | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
index 4103ed7afcde..6f6a0f13465f 100644
--- a/tools/testing/selftests/net/forwarding/lib.sh
+++ b/tools/testing/selftests/net/forwarding/lib.sh
@@ -84,6 +84,16 @@ declare -A NETIFS=(
 # e.g. a low-power board.
 : "${KSFT_MACHINE_SLOW:=no}"
 
+if [[ "$(id -u)" -ne 0 ]]; then
+	echo "SKIP: need root privileges"
+	exit $ksft_skip
+fi
+
+if [[ ! -v NUM_NETIFS ]]; then
+	echo "SKIP: importer does not define \"NUM_NETIFS\""
+	exit $ksft_skip
+fi
+
 net_forwarding_dir=$(dirname "$(readlink -e "${BASH_SOURCE[0]}")")
 
 if [[ -f $net_forwarding_dir/forwarding.config ]]; then
@@ -259,11 +269,6 @@ check_port_mab_support()
 	fi
 }
 
-if [[ "$(id -u)" -ne 0 ]]; then
-	echo "SKIP: need root privileges"
-	exit $ksft_skip
-fi
-
 if [[ "$CHECK_TC" = "yes" ]]; then
 	check_tc_version
 fi
@@ -291,11 +296,6 @@ if [[ "$REQUIRE_MTOOLS" = "yes" ]]; then
 	require_command mreceive
 fi
 
-if [[ ! -v NUM_NETIFS ]]; then
-	echo "SKIP: importer does not define \"NUM_NETIFS\""
-	exit $ksft_skip
-fi
-
 ##############################################################################
 # Command line options handling
 
-- 
2.44.0

[patch net-next 3/6] selftests: forwarding: add ability to assemble NETIFS array by driver name

[Jiri Pirko]

From: Jiri Pirko <jiri@nvidia.com>

Allow driver tests to work without specifying the netdevice names.
Introduce a possibility to search for available netdevices according to
set driver name. Allow test to specify the name by setting
NETIF_FIND_DRIVER variable.

Note that user overrides this either by passing netdevice names on the
command line or by declaring NETIFS array in custom forwarding.config
configuration file.

Signed-off-by: Jiri Pirko <jiri@nvidia.com>
---
 tools/testing/selftests/net/forwarding/lib.sh | 39 +++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
index 6f6a0f13465f..06633518b3aa 100644
--- a/tools/testing/selftests/net/forwarding/lib.sh
+++ b/tools/testing/selftests/net/forwarding/lib.sh
@@ -55,6 +55,9 @@ declare -A NETIFS=(
 : "${NETIF_CREATE:=yes}"
 : "${NETIF_TYPE:=veth}"
 
+# Whether to find netdevice according to the specified driver.
+: "${NETIF_FIND_DRIVER:=}"
+
 # Constants for ping tests:
 # How many packets should be sent.
 : "${PING_COUNT:=10}"
@@ -94,6 +97,42 @@ if [[ ! -v NUM_NETIFS ]]; then
 	exit $ksft_skip
 fi
 
+##############################################################################
+# Find netifs by test-specified driver name
+
+driver_name_get()
+{
+	local dev=$1; shift
+	local driver_path="/sys/class/net/$dev/device/driver"
+
+	if [ ! -L $driver_path ]; then
+		echo ""
+	else
+		basename `realpath $driver_path`
+	fi
+}
+
+find_netif()
+{
+	local ifnames=`ip -j -p link show | jq -e -r ".[].ifname"`
+	local count=0
+
+	for ifname in $ifnames
+	do
+		local driver_name=`driver_name_get $ifname`
+		if [[ ! -z $driver_name && $driver_name == $NETIF_FIND_DRIVER ]]; then
+			count=$((count + 1))
+			NETIFS[p$count]="$ifname"
+		fi
+	done
+}
+
+if [[ ! -z $NETIF_FIND_DRIVER ]]; then
+	unset NETIFS
+	declare -A NETIFS
+	find_netif
+fi
+
 net_forwarding_dir=$(dirname "$(readlink -e "${BASH_SOURCE[0]}")")
 
 if [[ -f $net_forwarding_dir/forwarding.config ]]; then
-- 
2.44.0

Re: [patch net-next 3/6] selftests: forwarding: add ability to assemble NETIFS array by driver name

[Benjamin Poirier]

On 2024-04-12 17:13 +0200, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@nvidia.com>
> 
> Allow driver tests to work without specifying the netdevice names.
> Introduce a possibility to search for available netdevices according to
> set driver name. Allow test to specify the name by setting
> NETIF_FIND_DRIVER variable.
> 
> Note that user overrides this either by passing netdevice names on the
> command line or by declaring NETIFS array in custom forwarding.config
> configuration file.
> 
> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
> ---
>  tools/testing/selftests/net/forwarding/lib.sh | 39 +++++++++++++++++++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
> index 6f6a0f13465f..06633518b3aa 100644
> --- a/tools/testing/selftests/net/forwarding/lib.sh
> +++ b/tools/testing/selftests/net/forwarding/lib.sh
> @@ -55,6 +55,9 @@ declare -A NETIFS=(
>  : "${NETIF_CREATE:=yes}"
>  : "${NETIF_TYPE:=veth}"
>  
> +# Whether to find netdevice according to the specified driver.
> +: "${NETIF_FIND_DRIVER:=}"
> +

This section of the file sets default values for variables that can be
set by users in forwarding.config. NETIF_FIND_DRIVER is more like
NUM_NETIFS, it is set by tests, so I don't think it should be listed
there.

>  # Constants for ping tests:
>  # How many packets should be sent.
>  : "${PING_COUNT:=10}"
> @@ -94,6 +97,42 @@ if [[ ! -v NUM_NETIFS ]]; then
>  	exit $ksft_skip
>  fi
>  
> +##############################################################################
> +# Find netifs by test-specified driver name
> +
> +driver_name_get()
> +{
> +	local dev=$1; shift
> +	local driver_path="/sys/class/net/$dev/device/driver"
> +
> +	if [ ! -L $driver_path ]; then
> +		echo ""
> +	else
> +		basename `realpath $driver_path`
> +	fi
> +}
> +
> +find_netif()
> +{
> +	local ifnames=`ip -j -p link show | jq -e -r ".[].ifname"`

-p and -e can be omitted

Re: [patch net-next 3/6] selftests: forwarding: add ability to assemble NETIFS array by driver name

[Jiri Pirko]

Fri, Apr 12, 2024 at 10:38:30PM CEST, benjamin.poirier@gmail.com wrote:
>On 2024-04-12 17:13 +0200, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@nvidia.com>
>> 
>> Allow driver tests to work without specifying the netdevice names.
>> Introduce a possibility to search for available netdevices according to
>> set driver name. Allow test to specify the name by setting
>> NETIF_FIND_DRIVER variable.
>> 
>> Note that user overrides this either by passing netdevice names on the
>> command line or by declaring NETIFS array in custom forwarding.config
>> configuration file.
>> 
>> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
>> ---
>>  tools/testing/selftests/net/forwarding/lib.sh | 39 +++++++++++++++++++
>>  1 file changed, 39 insertions(+)
>> 
>> diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
>> index 6f6a0f13465f..06633518b3aa 100644
>> --- a/tools/testing/selftests/net/forwarding/lib.sh
>> +++ b/tools/testing/selftests/net/forwarding/lib.sh
>> @@ -55,6 +55,9 @@ declare -A NETIFS=(
>>  : "${NETIF_CREATE:=yes}"
>>  : "${NETIF_TYPE:=veth}"
>>  
>> +# Whether to find netdevice according to the specified driver.
>> +: "${NETIF_FIND_DRIVER:=}"
>> +
>
>This section of the file sets default values for variables that can be
>set by users in forwarding.config. NETIF_FIND_DRIVER is more like
>NUM_NETIFS, it is set by tests, so I don't think it should be listed
>there.

Well, currently there is a mixture of config variables and test
definitions/requirements. For example REQUIRE_JQ, REQUIRE_MZ, REQUIRE_MTOOLS
are not forwarding.config configurable (they are, they should not be ;))

Where do you suggest to move NETIF_FIND_DRIVER?


>
>>  # Constants for ping tests:
>>  # How many packets should be sent.
>>  : "${PING_COUNT:=10}"
>> @@ -94,6 +97,42 @@ if [[ ! -v NUM_NETIFS ]]; then
>>  	exit $ksft_skip
>>  fi
>>  
>> +##############################################################################
>> +# Find netifs by test-specified driver name
>> +
>> +driver_name_get()
>> +{
>> +	local dev=$1; shift
>> +	local driver_path="/sys/class/net/$dev/device/driver"
>> +
>> +	if [ ! -L $driver_path ]; then
>> +		echo ""
>> +	else
>> +		basename `realpath $driver_path`
>> +	fi
>> +}
>> +
>> +find_netif()
>> +{
>> +	local ifnames=`ip -j -p link show | jq -e -r ".[].ifname"`
>
>-p and -e can be omitted

True. Will remove them.

Re: [patch net-next 3/6] selftests: forwarding: add ability to assemble NETIFS array by driver name

[Benjamin Poirier]

On 2024-04-13 15:27 +0200, Jiri Pirko wrote:
> Fri, Apr 12, 2024 at 10:38:30PM CEST, benjamin.poirier@gmail.com wrote:
> >On 2024-04-12 17:13 +0200, Jiri Pirko wrote:
> >> From: Jiri Pirko <jiri@nvidia.com>
> >> 
> >> Allow driver tests to work without specifying the netdevice names.
> >> Introduce a possibility to search for available netdevices according to
> >> set driver name. Allow test to specify the name by setting
> >> NETIF_FIND_DRIVER variable.
> >> 
> >> Note that user overrides this either by passing netdevice names on the
> >> command line or by declaring NETIFS array in custom forwarding.config
> >> configuration file.
> >> 
> >> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
> >> ---
> >>  tools/testing/selftests/net/forwarding/lib.sh | 39 +++++++++++++++++++
> >>  1 file changed, 39 insertions(+)
> >> 
> >> diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
> >> index 6f6a0f13465f..06633518b3aa 100644
> >> --- a/tools/testing/selftests/net/forwarding/lib.sh
> >> +++ b/tools/testing/selftests/net/forwarding/lib.sh
> >> @@ -55,6 +55,9 @@ declare -A NETIFS=(
> >>  : "${NETIF_CREATE:=yes}"
> >>  : "${NETIF_TYPE:=veth}"
> >>  
> >> +# Whether to find netdevice according to the specified driver.
> >> +: "${NETIF_FIND_DRIVER:=}"
> >> +
> >
> >This section of the file sets default values for variables that can be
> >set by users in forwarding.config. NETIF_FIND_DRIVER is more like
> >NUM_NETIFS, it is set by tests, so I don't think it should be listed
> >there.
> 
> Well, currently there is a mixture of config variables and test
> definitions/requirements. For example REQUIRE_JQ, REQUIRE_MZ, REQUIRE_MTOOLS
> are not forwarding.config configurable (they are, they should not be ;))

Yes, that's true. If you prefer to leave that statement there, go ahead.

> Where do you suggest to move NETIF_FIND_DRIVER?

I would make NETIF_FIND_DRIVER like NUM_NETIFS, ie. there's no statement
setting a default value for it. And I would move the comment describing
its purpose above this new part:

> +
> +if [[ ! -z $NETIF_FIND_DRIVER ]]; then
> +	unset NETIFS
> +	declare -A NETIFS
> +	find_netif
> +fi
> +

BTW, '! -z' can be removed from that test. It's equivalent to:
if [[ $NETIF_FIND_DRIVER ]]; then

Re: [patch net-next 3/6] selftests: forwarding: add ability to assemble NETIFS array by driver name

[Jiri Pirko]

Sun, Apr 14, 2024 at 09:32:46PM CEST, benjamin.poirier@gmail.com wrote:
>On 2024-04-13 15:27 +0200, Jiri Pirko wrote:
>> Fri, Apr 12, 2024 at 10:38:30PM CEST, benjamin.poirier@gmail.com wrote:
>> >On 2024-04-12 17:13 +0200, Jiri Pirko wrote:
>> >> From: Jiri Pirko <jiri@nvidia.com>
>> >> 
>> >> Allow driver tests to work without specifying the netdevice names.
>> >> Introduce a possibility to search for available netdevices according to
>> >> set driver name. Allow test to specify the name by setting
>> >> NETIF_FIND_DRIVER variable.
>> >> 
>> >> Note that user overrides this either by passing netdevice names on the
>> >> command line or by declaring NETIFS array in custom forwarding.config
>> >> configuration file.
>> >> 
>> >> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
>> >> ---
>> >>  tools/testing/selftests/net/forwarding/lib.sh | 39 +++++++++++++++++++
>> >>  1 file changed, 39 insertions(+)
>> >> 
>> >> diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
>> >> index 6f6a0f13465f..06633518b3aa 100644
>> >> --- a/tools/testing/selftests/net/forwarding/lib.sh
>> >> +++ b/tools/testing/selftests/net/forwarding/lib.sh
>> >> @@ -55,6 +55,9 @@ declare -A NETIFS=(
>> >>  : "${NETIF_CREATE:=yes}"
>> >>  : "${NETIF_TYPE:=veth}"
>> >>  
>> >> +# Whether to find netdevice according to the specified driver.
>> >> +: "${NETIF_FIND_DRIVER:=}"
>> >> +
>> >
>> >This section of the file sets default values for variables that can be
>> >set by users in forwarding.config. NETIF_FIND_DRIVER is more like
>> >NUM_NETIFS, it is set by tests, so I don't think it should be listed
>> >there.
>> 
>> Well, currently there is a mixture of config variables and test
>> definitions/requirements. For example REQUIRE_JQ, REQUIRE_MZ, REQUIRE_MTOOLS
>> are not forwarding.config configurable (they are, they should not be ;))
>
>Yes, that's true. If you prefer to leave that statement there, go ahead.
>
>> Where do you suggest to move NETIF_FIND_DRIVER?
>
>I would make NETIF_FIND_DRIVER like NUM_NETIFS, ie. there's no statement
>setting a default value for it. And I would move the comment describing
>its purpose above this new part:

Ok.

>
>> +
>> +if [[ ! -z $NETIF_FIND_DRIVER ]]; then
>> +	unset NETIFS
>> +	declare -A NETIFS
>> +	find_netif
>> +fi
>> +
>
>BTW, '! -z' can be removed from that test. It's equivalent to:
>if [[ $NETIF_FIND_DRIVER ]]; then

Ok.

[patch net-next 4/6] selftests: forwarding: add check_driver() helper

[Jiri Pirko]

From: Jiri Pirko <jiri@nvidia.com>

Add a helper to be used to check if the netdevice is backed by specified
driver.

Signed-off-by: Jiri Pirko <jiri@nvidia.com>
---
 tools/testing/selftests/net/forwarding/lib.sh | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
index 06633518b3aa..959183b516ce 100644
--- a/tools/testing/selftests/net/forwarding/lib.sh
+++ b/tools/testing/selftests/net/forwarding/lib.sh
@@ -308,6 +308,18 @@ check_port_mab_support()
 	fi
 }
 
+check_driver()
+{
+	local dev=$1; shift
+	local expected=$1; shift
+	local driver_name=`driver_name_get $dev`
+
+	if [[ $driver_name != $expected ]]; then
+		echo "SKIP: expected driver $expected for $dev, got $driver_name instead"
+		exit $ksft_skip
+	fi
+}
+
 if [[ "$CHECK_TC" = "yes" ]]; then
 	check_tc_version
 fi
-- 
2.44.0

[patch net-next 5/6] selftests: forwarding: add wait_for_dev() helper

[Jiri Pirko]

From: Jiri Pirko <jiri@nvidia.com>

The existing setup_wait*() helper family check the status of the
interface to be up. Introduce wait_for_dev() to wait for the netdevice
to appear, for example after test script does manual device bind.

Signed-off-by: Jiri Pirko <jiri@nvidia.com>
---
 tools/testing/selftests/net/forwarding/lib.sh | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
index 959183b516ce..74859f969997 100644
--- a/tools/testing/selftests/net/forwarding/lib.sh
+++ b/tools/testing/selftests/net/forwarding/lib.sh
@@ -746,6 +746,25 @@ setup_wait()
 	sleep $WAIT_TIME
 }
 
+wait_for_dev()
+{
+	local dev=$1; shift
+	local timeout=${1:-$WAIT_TIMEOUT}; shift
+	local max_iterations=$(($timeout * 10))
+
+	for ((i = 1; i <= $max_iterations; ++i)); do
+		ip link show dev $dev up &> /dev/null
+		if [[ $? -ne 0 ]]; then
+			sleep 0.1
+		else
+			return 0
+		fi
+	done
+
+	log_test wait_for_dev ": Interface $dev did not appear."
+	exit 1
+}
+
 cmd_jq()
 {
 	local cmd=$1
-- 
2.44.0

Re: [patch net-next 5/6] selftests: forwarding: add wait_for_dev() helper

[Benjamin Poirier]

On 2024-04-12 17:13 +0200, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@nvidia.com>
> 
> The existing setup_wait*() helper family check the status of the
> interface to be up. Introduce wait_for_dev() to wait for the netdevice
> to appear, for example after test script does manual device bind.
> 
> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
> ---
>  tools/testing/selftests/net/forwarding/lib.sh | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
> index 959183b516ce..74859f969997 100644
> --- a/tools/testing/selftests/net/forwarding/lib.sh
> +++ b/tools/testing/selftests/net/forwarding/lib.sh
> @@ -746,6 +746,25 @@ setup_wait()
>  	sleep $WAIT_TIME
>  }
>  
> +wait_for_dev()
> +{
> +	local dev=$1; shift
> +	local timeout=${1:-$WAIT_TIMEOUT}; shift
> +	local max_iterations=$(($timeout * 10))
> +
> +	for ((i = 1; i <= $max_iterations; ++i)); do
> +		ip link show dev $dev up &> /dev/null
> +		if [[ $? -ne 0 ]]; then
> +			sleep 0.1
> +		else
> +			return 0
> +		fi
> +	done
> +
> +	log_test wait_for_dev ": Interface $dev did not appear."
> +	exit 1
> +}

How about rewriting the function to make use of the `slowwait` helper as
follows:

wait_for_dev()
{
	local dev=$1; shift
	local timeout=${1:-$WAIT_TIMEOUT}; shift

	slowwait $timeout ip link show dev $dev up &> /dev/null
	if (( $? )); then
		check_err 1
		log_test wait_for_dev "Interface $dev did not appear."
		exit $EXIT_STATUS
	fi
}

Re: [patch net-next 5/6] selftests: forwarding: add wait_for_dev() helper

[Jiri Pirko]

Fri, Apr 12, 2024 at 10:43:40PM CEST, benjamin.poirier@gmail.com wrote:
>On 2024-04-12 17:13 +0200, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@nvidia.com>
>> 
>> The existing setup_wait*() helper family check the status of the
>> interface to be up. Introduce wait_for_dev() to wait for the netdevice
>> to appear, for example after test script does manual device bind.
>> 
>> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
>> ---
>>  tools/testing/selftests/net/forwarding/lib.sh | 19 +++++++++++++++++++
>>  1 file changed, 19 insertions(+)
>> 
>> diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
>> index 959183b516ce..74859f969997 100644
>> --- a/tools/testing/selftests/net/forwarding/lib.sh
>> +++ b/tools/testing/selftests/net/forwarding/lib.sh
>> @@ -746,6 +746,25 @@ setup_wait()
>>  	sleep $WAIT_TIME
>>  }
>>  
>> +wait_for_dev()
>> +{
>> +	local dev=$1; shift
>> +	local timeout=${1:-$WAIT_TIMEOUT}; shift
>> +	local max_iterations=$(($timeout * 10))
>> +
>> +	for ((i = 1; i <= $max_iterations; ++i)); do
>> +		ip link show dev $dev up &> /dev/null
>> +		if [[ $? -ne 0 ]]; then
>> +			sleep 0.1
>> +		else
>> +			return 0
>> +		fi
>> +	done
>> +
>> +	log_test wait_for_dev ": Interface $dev did not appear."
>> +	exit 1
>> +}
>
>How about rewriting the function to make use of the `slowwait` helper as
>follows:
>
>wait_for_dev()
>{
>	local dev=$1; shift
>	local timeout=${1:-$WAIT_TIMEOUT}; shift
>
>	slowwait $timeout ip link show dev $dev up &> /dev/null
>	if (( $? )); then
>		check_err 1
>		log_test wait_for_dev "Interface $dev did not appear."
>		exit $EXIT_STATUS
>	fi
>}

Sure, will redo this. Thanks!

[patch net-next 6/6] selftests: virtio_net: add initial tests

[Jiri Pirko]

From: Jiri Pirko <jiri@nvidia.com>

Introduce initial tests for virtio_net driver. Focus on feature testing
leveraging previously introduced debugfs feature filtering
infrastructure. Add very basic ping and F_MAC feature tests.

To run this, do:
$ make -C tools/testing/selftests/ TARGETS=drivers/net/virtio_net/ run_tests

Run it on a system with 2 virtio_net devices connected back-to-back
on the hypervisor.

Signed-off-by: Jiri Pirko <jiri@nvidia.com>
---
 tools/testing/selftests/Makefile              |   1 +
 .../selftests/drivers/net/virtio_net/Makefile |   5 +
 .../drivers/net/virtio_net/basic_features.sh  | 127 ++++++++++++++++++
 .../net/virtio_net/virtio_net_common.sh       |  99 ++++++++++++++
 4 files changed, 232 insertions(+)
 create mode 100644 tools/testing/selftests/drivers/net/virtio_net/Makefile
 create mode 100755 tools/testing/selftests/drivers/net/virtio_net/basic_features.sh
 create mode 100644 tools/testing/selftests/drivers/net/virtio_net/virtio_net_common.sh

diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 6dab886d6f7a..a8e40599c65f 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -20,6 +20,7 @@ TARGETS += drivers/s390x/uvdevice
 TARGETS += drivers/net
 TARGETS += drivers/net/bonding
 TARGETS += drivers/net/team
+TARGETS += drivers/net/virtio
 TARGETS += dt
 TARGETS += efivarfs
 TARGETS += exec
diff --git a/tools/testing/selftests/drivers/net/virtio_net/Makefile b/tools/testing/selftests/drivers/net/virtio_net/Makefile
new file mode 100644
index 000000000000..c6edf5ddb0e4
--- /dev/null
+++ b/tools/testing/selftests/drivers/net/virtio_net/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0+ OR MIT
+
+TEST_PROGS = basic_features.sh
+
+include ../../../lib.mk
diff --git a/tools/testing/selftests/drivers/net/virtio_net/basic_features.sh b/tools/testing/selftests/drivers/net/virtio_net/basic_features.sh
new file mode 100755
index 000000000000..b9047299b510
--- /dev/null
+++ b/tools/testing/selftests/drivers/net/virtio_net/basic_features.sh
@@ -0,0 +1,127 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+# See virtio_net_common.sh comments for more details about assumed setup
+
+ALL_TESTS="
+	initial_ping_test
+	f_mac_test
+"
+
+source virtio_net_common.sh
+
+lib_dir=$(dirname "$0")
+source "$lib_dir"/../../../net/forwarding/lib.sh
+
+h1=${NETIFS[p1]}
+h2=${NETIFS[p2]}
+
+h1_create()
+{
+	simple_if_init $h1 $H1_IPV4/24 $H1_IPV6/64
+}
+
+h1_destroy()
+{
+	simple_if_fini $h1 $H1_IPV4/24 $H1_IPV6/64
+}
+
+h2_create()
+{
+	simple_if_init $h2 $H2_IPV4/24 $H2_IPV6/64
+}
+
+h2_destroy()
+{
+	simple_if_fini $h2 $H2_IPV4/24 $H2_IPV6/64
+}
+
+initial_ping_test()
+{
+	cleanup
+	setup_prepare
+	ping_test $h1 $H2_IPV4 " simple"
+}
+
+f_mac_test()
+{
+	RET=0
+	local test_name="mac feature filtered"
+
+	virtio_feature_present $h1 $VIRTIO_NET_F_MAC
+	if [ $? -ne 0 ]; then
+		log_test_skip "$test_name" "Device $h1 is missing feature $VIRTIO_NET_F_MAC."
+		return 0
+	fi
+	virtio_feature_present $h1 $VIRTIO_NET_F_MAC
+	if [ $? -ne 0 ]; then
+		log_test_skip "$test_name" "Device $h2 is missing feature $VIRTIO_NET_F_MAC."
+		return 0
+	fi
+
+	cleanup
+	setup_prepare
+
+	grep -q 0 /sys/class/net/$h1/addr_assign_type
+	check_err $? "Permanent address assign type for $h1 is not set"
+	grep -q 0 /sys/class/net/$h2/addr_assign_type
+	check_err $? "Permanent address assign type for $h2 is not set"
+
+	cleanup
+	virtio_filter_feature_add $h1 $VIRTIO_NET_F_MAC
+	virtio_filter_feature_add $h2 $VIRTIO_NET_F_MAC
+	setup_prepare
+
+	grep -q 0 /sys/class/net/$h1/addr_assign_type
+	check_fail $? "Permanent address assign type for $h1 is set when F_MAC feature is filtered"
+	grep -q 0 /sys/class/net/$h2/addr_assign_type
+	check_fail $? "Permanent address assign type for $h2 is set when F_MAC feature is filtered"
+
+	ping_do $h1 $H2_IPV4
+	check_err $? "Ping failed"
+
+	log_test "$test_name"
+}
+
+setup_prepare()
+{
+	virtio_device_rebind $h1
+	virtio_device_rebind $h2
+	wait_for_dev $h1
+	wait_for_dev $h2
+
+	vrf_prepare
+
+	h1_create
+	h2_create
+}
+
+cleanup()
+{
+	pre_cleanup
+
+	h2_destroy
+	h1_destroy
+
+	vrf_cleanup
+
+	virtio_filter_features_clear $h1
+	virtio_filter_features_clear $h2
+	virtio_device_rebind $h1
+	virtio_device_rebind $h2
+	wait_for_dev $h1
+	wait_for_dev $h2
+}
+
+check_driver $h1 "virtio_net"
+check_driver $h2 "virtio_net"
+check_virtio_debugfs $h1
+check_virtio_debugfs $h2
+
+trap cleanup EXIT
+
+setup_prepare
+
+tests_run
+
+exit "$EXIT_STATUS"
diff --git a/tools/testing/selftests/drivers/net/virtio_net/virtio_net_common.sh b/tools/testing/selftests/drivers/net/virtio_net/virtio_net_common.sh
new file mode 100644
index 000000000000..57bd8055e2e5
--- /dev/null
+++ b/tools/testing/selftests/drivers/net/virtio_net/virtio_net_common.sh
@@ -0,0 +1,99 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+# This assumes running on a host with two virtio interfaces connected
+# back to back. Example script to do such wire-up of tap devices would
+# look like this:
+#
+# =======================================================================================================
+# #!/bin/bash
+#
+# DEV1="$1"
+# DEV2="$2"
+#
+# sudo tc qdisc add dev $DEV1 clsact
+# sudo tc qdisc add dev $DEV2 clsact
+# sudo tc filter add dev $DEV1 ingress protocol all pref 1 matchall action mirred egress redirect dev $DEV2
+# sudo tc filter add dev $DEV2 ingress protocol all pref 1 matchall action mirred egress redirect dev $DEV1
+# sudo ip link set $DEV1 up
+# sudo ip link set $DEV2 up
+# =======================================================================================================
+
+REQUIRE_MZ="no"
+NETIF_CREATE="no"
+NETIF_FIND_DRIVER="virtio_net"
+NUM_NETIFS=2
+
+H1_IPV4="192.0.2.1"
+H2_IPV4="192.0.2.2"
+H1_IPV6="2001:db8:1::1"
+H2_IPV6="2001:db8:1::2"
+
+VIRTIO_NET_F_MAC=5
+
+virtio_device_get()
+{
+	local dev=$1; shift
+	local device_path="/sys/class/net/$dev/device/"
+
+	basename `realpath $device_path`
+}
+
+virtio_device_rebind()
+{
+	local dev=$1; shift
+	local device=`virtio_device_get $dev`
+
+	echo "$device" > /sys/bus/virtio/drivers/virtio_net/unbind
+	echo "$device" > /sys/bus/virtio/drivers/virtio_net/bind
+}
+
+virtio_debugfs_get()
+{
+	local dev=$1; shift
+	local device=`virtio_device_get $dev`
+
+	echo /sys/kernel/debug/virtio/$device/
+}
+
+check_virtio_debugfs()
+{
+	local dev=$1; shift
+	local debugfs=`virtio_debugfs_get $dev`
+
+	if [ ! -f "$debugfs/device_features" ] ||
+	   [ ! -f "$debugfs/filter_feature_add"  ] ||
+	   [ ! -f "$debugfs/filter_feature_del"  ] ||
+	   [ ! -f "$debugfs/filter_features"  ] ||
+	   [ ! -f "$debugfs/filter_features_clear"  ]; then
+		echo "SKIP: not possible to access debugfs for $dev"
+		exit $ksft_skip
+	fi
+}
+
+virtio_feature_present()
+{
+	local dev=$1; shift
+	local feature=$1; shift
+	local debugfs=`virtio_debugfs_get $dev`
+
+	cat $debugfs/device_features |grep "^$feature$" &> /dev/null
+	return $?
+}
+
+virtio_filter_features_clear()
+{
+	local dev=$1; shift
+	local debugfs=`virtio_debugfs_get $dev`
+
+	echo "1" > $debugfs/filter_features_clear
+}
+
+virtio_filter_feature_add()
+{
+	local dev=$1; shift
+	local feature=$1; shift
+	local debugfs=`virtio_debugfs_get $dev`
+
+	echo "$feature" > $debugfs/filter_feature_add
+}
-- 
2.44.0

Re: [patch net-next 6/6] selftests: virtio_net: add initial tests

[Benjamin Poirier]

On 2024-04-12 17:13 +0200, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@nvidia.com>
> 
> Introduce initial tests for virtio_net driver. Focus on feature testing
> leveraging previously introduced debugfs feature filtering
> infrastructure. Add very basic ping and F_MAC feature tests.
> 
> To run this, do:
> $ make -C tools/testing/selftests/ TARGETS=drivers/net/virtio_net/ run_tests
> 
> Run it on a system with 2 virtio_net devices connected back-to-back
> on the hypervisor.
> 
> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
> ---
>  tools/testing/selftests/Makefile              |   1 +
>  .../selftests/drivers/net/virtio_net/Makefile |   5 +
>  .../drivers/net/virtio_net/basic_features.sh  | 127 ++++++++++++++++++
>  .../net/virtio_net/virtio_net_common.sh       |  99 ++++++++++++++
>  4 files changed, 232 insertions(+)
>  create mode 100644 tools/testing/selftests/drivers/net/virtio_net/Makefile
>  create mode 100755 tools/testing/selftests/drivers/net/virtio_net/basic_features.sh
>  create mode 100644 tools/testing/selftests/drivers/net/virtio_net/virtio_net_common.sh
> 
> diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
> index 6dab886d6f7a..a8e40599c65f 100644
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@ -20,6 +20,7 @@ TARGETS += drivers/s390x/uvdevice
>  TARGETS += drivers/net
>  TARGETS += drivers/net/bonding
>  TARGETS += drivers/net/team
> +TARGETS += drivers/net/virtio
>  TARGETS += dt
>  TARGETS += efivarfs
>  TARGETS += exec
> diff --git a/tools/testing/selftests/drivers/net/virtio_net/Makefile b/tools/testing/selftests/drivers/net/virtio_net/Makefile
> new file mode 100644
> index 000000000000..c6edf5ddb0e4
> --- /dev/null
> +++ b/tools/testing/selftests/drivers/net/virtio_net/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0+ OR MIT
> +
> +TEST_PROGS = basic_features.sh
> +
> +include ../../../lib.mk

Makefile is missing something like

TEST_FILES = \
	virtio_net_common.sh \
	#

TEST_INCLUDES = \
	../../../net/forwarding/lib.sh \
	../../../net/lib.sh \
	#

Without those, these files are missing when exporting the tests, such as
with:

cd tools/testing/selftests/
make install TARGETS=drivers/net/virtio_net/
./kselftest_install/run_kselftest.sh

Re: [patch net-next 6/6] selftests: virtio_net: add initial tests

[Jiri Pirko]

Fri, Apr 12, 2024 at 10:46:58PM CEST, benjamin.poirier@gmail.com wrote:
>On 2024-04-12 17:13 +0200, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@nvidia.com>
>> 
>> Introduce initial tests for virtio_net driver. Focus on feature testing
>> leveraging previously introduced debugfs feature filtering
>> infrastructure. Add very basic ping and F_MAC feature tests.
>> 
>> To run this, do:
>> $ make -C tools/testing/selftests/ TARGETS=drivers/net/virtio_net/ run_tests
>> 
>> Run it on a system with 2 virtio_net devices connected back-to-back
>> on the hypervisor.
>> 
>> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
>> ---
>>  tools/testing/selftests/Makefile              |   1 +
>>  .../selftests/drivers/net/virtio_net/Makefile |   5 +
>>  .../drivers/net/virtio_net/basic_features.sh  | 127 ++++++++++++++++++
>>  .../net/virtio_net/virtio_net_common.sh       |  99 ++++++++++++++
>>  4 files changed, 232 insertions(+)
>>  create mode 100644 tools/testing/selftests/drivers/net/virtio_net/Makefile
>>  create mode 100755 tools/testing/selftests/drivers/net/virtio_net/basic_features.sh
>>  create mode 100644 tools/testing/selftests/drivers/net/virtio_net/virtio_net_common.sh
>> 
>> diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
>> index 6dab886d6f7a..a8e40599c65f 100644
>> --- a/tools/testing/selftests/Makefile
>> +++ b/tools/testing/selftests/Makefile
>> @@ -20,6 +20,7 @@ TARGETS += drivers/s390x/uvdevice
>>  TARGETS += drivers/net
>>  TARGETS += drivers/net/bonding
>>  TARGETS += drivers/net/team
>> +TARGETS += drivers/net/virtio
>>  TARGETS += dt
>>  TARGETS += efivarfs
>>  TARGETS += exec
>> diff --git a/tools/testing/selftests/drivers/net/virtio_net/Makefile b/tools/testing/selftests/drivers/net/virtio_net/Makefile
>> new file mode 100644
>> index 000000000000..c6edf5ddb0e4
>> --- /dev/null
>> +++ b/tools/testing/selftests/drivers/net/virtio_net/Makefile
>> @@ -0,0 +1,5 @@
>> +# SPDX-License-Identifier: GPL-2.0+ OR MIT
>> +
>> +TEST_PROGS = basic_features.sh
>> +
>> +include ../../../lib.mk
>
>Makefile is missing something like
>
>TEST_FILES = \
>	virtio_net_common.sh \
>	#
>
>TEST_INCLUDES = \
>	../../../net/forwarding/lib.sh \
>	../../../net/lib.sh \
>	#
>
>Without those, these files are missing when exporting the tests, such as
>with:
>
>cd tools/testing/selftests/
>make install TARGETS=drivers/net/virtio_net/
>./kselftest_install/run_kselftest.sh

Ah, will try and fix. Thanks!

Re: [patch net-next 0/6] selftests: virtio_net: introduce initial testing infrastructure

[Jakub Kicinski]

On Fri, 12 Apr 2024 17:13:08 +0200 Jiri Pirko wrote:
> This patchset aims at introducing very basic initial infrastructure
> for virtio_net testing, namely it focuses on virtio feature testing.
> 
> The first patch adds support for debugfs for virtio devices, allowing
> user to filter features to pretend to be driver that is not capable
> of the filtered feature.

Two trivial points: MAINTAINERS should probably be updated to bestow
the responsibility over these to virtio folks; there should probably
be a config file. Admittedly anyone testing in a VM should have VIRTIO
and anyone not in a VM won't test this... but it's a good practice.

Did you investigate how hard it would be to make virtme-ng pop out
two virtio interfaces?  It's a pretty hackable Python code base and
Andrea is very responsive so would be nice to get that done. And then
its trivial to run those in our CI.

Re: [patch net-next 0/6] selftests: virtio_net: introduce initial testing infrastructure

[Jiri Pirko]

Sat, Apr 13, 2024 at 03:04:28AM CEST, kuba@kernel.org wrote:
>On Fri, 12 Apr 2024 17:13:08 +0200 Jiri Pirko wrote:
>> This patchset aims at introducing very basic initial infrastructure
>> for virtio_net testing, namely it focuses on virtio feature testing.
>> 
>> The first patch adds support for debugfs for virtio devices, allowing
>> user to filter features to pretend to be driver that is not capable
>> of the filtered feature.
>
>Two trivial points: MAINTAINERS should probably be updated to bestow
>the responsibility over these to virtio folks; there should probably
>be a config file. Admittedly anyone testing in a VM should have VIRTIO
>and anyone not in a VM won't test this... but it's a good practice.

Sure, will add these 2.


>
>Did you investigate how hard it would be to make virtme-ng pop out
>two virtio interfaces?  It's a pretty hackable Python code base and
>Andrea is very responsive so would be nice to get that done. And then
>its trivial to run those in our CI.

That is a goal. Currently I do it with:
vng --qemu-opts="-nic tap,id=nd0,ifname=xtap0,model=virtio-net-pci,script=no,downscript=no,mac=52:54:00:12:34:57 -nic tap,id=nd1,ifname=xtap1,model=virtio-net-pci,script=no,downscript=no,mac=52:54:00:12:34:58"

and setting loop manually with tc-matchall-mirred

Implementing virtio loop instantiation in vng is on the todo list for
this.

Re: [patch net-next 0/6] selftests: virtio_net: introduce initial testing infrastructure

[Jakub Kicinski]

On Sat, 13 Apr 2024 15:23:53 +0200 Jiri Pirko wrote:
> That is a goal. Currently I do it with:
> vng --qemu-opts="-nic tap,id=nd0,ifname=xtap0,model=virtio-net-pci,script=no,downscript=no,mac=52:54:00:12:34:57 -nic tap,id=nd1,ifname=xtap1,model=virtio-net-pci,script=no,downscript=no,mac=52:54:00:12:34:58"
> 
> and setting loop manually with tc-matchall-mirred
> 
> Implementing virtio loop instantiation in vng is on the todo list for
> this.

Just to be clear - I think the loop configuration is better off outside
vng. It may need SUID and such. We just need to make vng spawn the two
interfaces with a less verbose syntax. --network-count 2 ?

Re: [patch net-next 0/6] selftests: virtio_net: introduce initial testing infrastructure

[Jiri Pirko]

Mon, Apr 15, 2024 at 07:26:59PM CEST, kuba@kernel.org wrote:
>On Sat, 13 Apr 2024 15:23:53 +0200 Jiri Pirko wrote:
>> That is a goal. Currently I do it with:
>> vng --qemu-opts="-nic tap,id=nd0,ifname=xtap0,model=virtio-net-pci,script=no,downscript=no,mac=52:54:00:12:34:57 -nic tap,id=nd1,ifname=xtap1,model=virtio-net-pci,script=no,downscript=no,mac=52:54:00:12:34:58"
>> 
>> and setting loop manually with tc-matchall-mirred
>> 
>> Implementing virtio loop instantiation in vng is on the todo list for
>> this.
>
>Just to be clear - I think the loop configuration is better off outside
>vng. It may need SUID and such. We just need to make vng spawn the two
>interfaces with a less verbose syntax. --network-count 2 ?

Well, you ask vng for network device by:
--net=user/bridge

Currently putting the option multiple times is ignored, but I don't see
why that can't work.

Regarding the loop configuration, I would like to make this as
convenient for the user as possible, I was thinking about something like
--net=loop which would create the tc-based loop.

How to do this without root, I'm not sure. Perhaps something similar
like qemu-bridge-helper could be used.

Re: [patch net-next 0/6] selftests: virtio_net: introduce initial testing infrastructure

[Jiri Pirko]

Tue, Apr 16, 2024 at 11:53:35AM CEST, jiri@resnulli.us wrote:
>Mon, Apr 15, 2024 at 07:26:59PM CEST, kuba@kernel.org wrote:
>>On Sat, 13 Apr 2024 15:23:53 +0200 Jiri Pirko wrote:
>>> That is a goal. Currently I do it with:
>>> vng --qemu-opts="-nic tap,id=nd0,ifname=xtap0,model=virtio-net-pci,script=no,downscript=no,mac=52:54:00:12:34:57 -nic tap,id=nd1,ifname=xtap1,model=virtio-net-pci,script=no,downscript=no,mac=52:54:00:12:34:58"
>>> 
>>> and setting loop manually with tc-matchall-mirred
>>> 
>>> Implementing virtio loop instantiation in vng is on the todo list for
>>> this.
>>
>>Just to be clear - I think the loop configuration is better off outside
>>vng. It may need SUID and such. We just need to make vng spawn the two
>>interfaces with a less verbose syntax. --network-count 2 ?
>
>Well, you ask vng for network device by:
>--net=user/bridge
>
>Currently putting the option multiple times is ignored, but I don't see
>why that can't work.
>
>Regarding the loop configuration, I would like to make this as
>convenient for the user as possible, I was thinking about something like
>--net=loop which would create the tc-based loop.
>
>How to do this without root, I'm not sure. Perhaps something similar
>like qemu-bridge-helper could be used.

Ha, qemu knows how to solve this already:
       -netdev hubport,id=id,hubid=hubid[,netdev=nd]
              Create a hub port on the emulated hub with ID hubid.

              The hubport netdev lets you connect a NIC to a QEMU emulated hub
              instead of a single netdev. Alternatively, you can also  connect
              the  hubport to another netdev with ID nd by using the netdev=nd
              option.

I cooked-up a testing vng patch, so the user can pass "--net=loop":
https://github.com/arighi/virtme-ng/commit/84a26ba92c9834c09d16fc1a4dc3a69c4d758236

Re: [patch net-next 0/6] selftests: virtio_net: introduce initial testing infrastructure

[Jason Wang]

On Tue, Apr 16, 2024 at 9:03 PM Jiri Pirko <jiri@resnulli.us> wrote:
>
> Tue, Apr 16, 2024 at 11:53:35AM CEST, jiri@resnulli.us wrote:
> >Mon, Apr 15, 2024 at 07:26:59PM CEST, kuba@kernel.org wrote:
> >>On Sat, 13 Apr 2024 15:23:53 +0200 Jiri Pirko wrote:
> >>> That is a goal. Currently I do it with:
> >>> vng --qemu-opts="-nic tap,id=nd0,ifname=xtap0,model=virtio-net-pci,script=no,downscript=no,mac=52:54:00:12:34:57 -nic tap,id=nd1,ifname=xtap1,model=virtio-net-pci,script=no,downscript=no,mac=52:54:00:12:34:58"
> >>>
> >>> and setting loop manually with tc-matchall-mirred
> >>>
> >>> Implementing virtio loop instantiation in vng is on the todo list for
> >>> this.
> >>
> >>Just to be clear - I think the loop configuration is better off outside
> >>vng. It may need SUID and such. We just need to make vng spawn the two
> >>interfaces with a less verbose syntax. --network-count 2 ?
> >
> >Well, you ask vng for network device by:
> >--net=user/bridge
> >
> >Currently putting the option multiple times is ignored, but I don't see
> >why that can't work.
> >
> >Regarding the loop configuration, I would like to make this as
> >convenient for the user as possible, I was thinking about something like
> >--net=loop which would create the tc-based loop.
> >
> >How to do this without root, I'm not sure. Perhaps something similar
> >like qemu-bridge-helper could be used.
>
> Ha, qemu knows how to solve this already:
>        -netdev hubport,id=id,hubid=hubid[,netdev=nd]
>               Create a hub port on the emulated hub with ID hubid.
>
>               The hubport netdev lets you connect a NIC to a QEMU emulated hub
>               instead of a single netdev. Alternatively, you can also  connect
>               the  hubport to another netdev with ID nd by using the netdev=nd
>               option.
>
> I cooked-up a testing vng patch, so the user can pass "--net=loop":
> https://github.com/arighi/virtme-ng/commit/84a26ba92c9834c09d16fc1a4dc3a69c4d758236
>

Note: another way, there's a vdpa(virto)-net simulator which can only
do loopback. The advantage is that you don't even need Qemu.

Thanks

>