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

[patch net-next v2 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

---
v1->v2:
- addressed comments from Jakub and Benjamin, see individual
  patches #3, #5 and #6 for details.

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

 MAINTAINERS                                   |   1 +
 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 |  15 +++
 .../drivers/net/virtio_net/basic_features.sh  | 127 ++++++++++++++++++
 .../selftests/drivers/net/virtio_net/config   |   2 +
 .../net/virtio_net/virtio_net_common.sh       |  99 ++++++++++++++
 tools/testing/selftests/net/forwarding/lib.sh |  82 +++++++++--
 12 files changed, 479 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/config
 create mode 100644 tools/testing/selftests/drivers/net/virtio_net/virtio_net_common.sh

-- 
2.44.0

[patch net-next v2 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 v2 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 v2 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>
---
v1->v2:
- removed unnecessary "-p" and "-e" options
- removed unnecessary "! -z" from the check
- moved NETIF_FIND_DRIVER declaration from the config options
---
 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..cc94de89bda3 100644
--- a/tools/testing/selftests/net/forwarding/lib.sh
+++ b/tools/testing/selftests/net/forwarding/lib.sh
@@ -94,6 +94,45 @@ 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 link show | jq -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
+}
+
+# Whether to find netdevice according to the specified driver.
+: "${NETIF_FIND_DRIVER:=}"
+
+if [[ $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

[patch net-next v2 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 cc94de89bda3..254698c6ba56 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 v2 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>
---
v1->v2:
- reworked wait_for_dev() helper to use slowwait() helper
---
 tools/testing/selftests/net/forwarding/lib.sh | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
index 254698c6ba56..e85b361dc85d 100644
--- a/tools/testing/selftests/net/forwarding/lib.sh
+++ b/tools/testing/selftests/net/forwarding/lib.sh
@@ -746,6 +746,19 @@ setup_wait()
 	sleep $WAIT_TIME
 }
 
+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
+}
+
 cmd_jq()
 {
 	local cmd=$1
-- 
2.44.0

[patch net-next v2 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>
---
v1->v2:
- added TEST_FILES and TEST_INCLUDES in the Makefile
- fixed directory name in selftests/Makefile
- added MAINTAINERS entry
- added config file with kernel config options
---
 MAINTAINERS                                   |   1 +
 tools/testing/selftests/Makefile              |   1 +
 .../selftests/drivers/net/virtio_net/Makefile |  15 +++
 .../drivers/net/virtio_net/basic_features.sh  | 127 ++++++++++++++++++
 .../selftests/drivers/net/virtio_net/config   |   2 +
 .../net/virtio_net/virtio_net_common.sh       |  99 ++++++++++++++
 6 files changed, 245 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/config
 create mode 100644 tools/testing/selftests/drivers/net/virtio_net/virtio_net_common.sh

diff --git a/MAINTAINERS b/MAINTAINERS
index 5ba3fe6ac09c..510b2115dae0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23443,6 +23443,7 @@ F:	include/linux/virtio*.h
 F:	include/linux/vringh.h
 F:	include/uapi/linux/virtio_*.h
 F:	tools/virtio/
+F:	tools/testing/selftests/drivers/net/virtio_net/
 
 VIRTIO CRYPTO DRIVER
 M:	Gonglei <arei.gonglei@huawei.com>
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 6dab886d6f7a..7873ad2f4800 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_net
 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..7ec7cd3ab2cc
--- /dev/null
+++ b/tools/testing/selftests/drivers/net/virtio_net/Makefile
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0+ OR MIT
+
+TEST_PROGS = basic_features.sh \
+        #
+
+TEST_FILES = \
+        virtio_net_common.sh \
+        #
+
+TEST_INCLUDES = \
+        ../../../net/forwarding/lib.sh \
+        ../../../net/lib.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/config b/tools/testing/selftests/drivers/net/virtio_net/config
new file mode 100644
index 000000000000..f35de0542b60
--- /dev/null
+++ b/tools/testing/selftests/drivers/net/virtio_net/config
@@ -0,0 +1,2 @@
+CONFIG_VIRTIO_NET=y
+CONFIG_VIRTIO_DEBUG=y
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 v2 5/6] selftests: forwarding: add wait_for_dev() helper

[Benjamin Poirier]

On 2024-04-15 18:25 +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>
> ---
> v1->v2:
> - reworked wait_for_dev() helper to use slowwait() helper
> ---
>  tools/testing/selftests/net/forwarding/lib.sh | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
> index 254698c6ba56..e85b361dc85d 100644
> --- a/tools/testing/selftests/net/forwarding/lib.sh
> +++ b/tools/testing/selftests/net/forwarding/lib.sh
> @@ -746,6 +746,19 @@ setup_wait()
>  	sleep $WAIT_TIME
>  }
>  
> +wait_for_dev()
> +{
> +        local dev=$1; shift
> +        local timeout=${1:-$WAIT_TIMEOUT}; shift
> +
> +        slowwait $timeout ip link show dev $dev up &> /dev/null

Sorry, I just noticed that this includes the "up" flag. I was confused
for a while until I realized that `ip` returns success even if the
interface is not up:

# ip link set dev eth1 down
# ip link show dev eth1 up
# echo $?
0

So wait_for_dev() really does just wait for the device to appear, not
for it to be up. If you agree, please remove the 'up' keyword to avoid
confusion.

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

[Jason Wang]

On Tue, Apr 16, 2024 at 12:25 AM Jiri Pirko <jiri@resnulli.us> wrote:
>
> 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>
> ---

Note that this can be done already with vp_vdpa feature provisioning:

commit c1ca352d371f724f7fb40f016abdb563aa85fe55
Author: Jason Wang <jasowang@redhat.com>
Date:   Tue Sep 27 15:48:10 2022 +0800

    vp_vdpa: support feature provisioning

For example:

vdpa dev add name dev1 mgmtdev pci/0000:02:00.0 device_features 0x300020000

Thanks

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

[Jiri Pirko]

Mon, Apr 15, 2024 at 11:39:42PM CEST, benjamin.poirier@gmail.com wrote:
>On 2024-04-15 18:25 +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>
>> ---
>> v1->v2:
>> - reworked wait_for_dev() helper to use slowwait() helper
>> ---
>>  tools/testing/selftests/net/forwarding/lib.sh | 13 +++++++++++++
>>  1 file changed, 13 insertions(+)
>> 
>> diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
>> index 254698c6ba56..e85b361dc85d 100644
>> --- a/tools/testing/selftests/net/forwarding/lib.sh
>> +++ b/tools/testing/selftests/net/forwarding/lib.sh
>> @@ -746,6 +746,19 @@ setup_wait()
>>  	sleep $WAIT_TIME
>>  }
>>  
>> +wait_for_dev()
>> +{
>> +        local dev=$1; shift
>> +        local timeout=${1:-$WAIT_TIMEOUT}; shift
>> +
>> +        slowwait $timeout ip link show dev $dev up &> /dev/null
>
>Sorry, I just noticed that this includes the "up" flag. I was confused
>for a while until I realized that `ip` returns success even if the
>interface is not up:
>
># ip link set dev eth1 down
># ip link show dev eth1 up
># echo $?
>0
>
>So wait_for_dev() really does just wait for the device to appear, not
>for it to be up. If you agree, please remove the 'up' keyword to avoid
>confusion.

That is the intension :) I don't care about it being up, I just need to
have it in the system.

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

[Jiri Pirko]

Tue, Apr 16, 2024 at 05:52:41AM CEST, jasowang@redhat.com wrote:
>On Tue, Apr 16, 2024 at 12:25 AM Jiri Pirko <jiri@resnulli.us> wrote:
>>
>> 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>
>> ---
>
>Note that this can be done already with vp_vdpa feature provisioning:
>
>commit c1ca352d371f724f7fb40f016abdb563aa85fe55
>Author: Jason Wang <jasowang@redhat.com>
>Date:   Tue Sep 27 15:48:10 2022 +0800
>
>    vp_vdpa: support feature provisioning
>
>For example:
>
>vdpa dev add name dev1 mgmtdev pci/0000:02:00.0 device_features 0x300020000

Sure. My intension was to make the testing possible on any virtio
device. Narrowing the testing for vpda would be limitting.


>
>Thanks
>

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

[Jason Wang]

On Tue, Apr 16, 2024 at 5:37 PM Jiri Pirko <jiri@resnulli.us> wrote:
>
> Tue, Apr 16, 2024 at 05:52:41AM CEST, jasowang@redhat.com wrote:
> >On Tue, Apr 16, 2024 at 12:25 AM Jiri Pirko <jiri@resnulli.us> wrote:
> >>
> >> 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>
> >> ---
> >
> >Note that this can be done already with vp_vdpa feature provisioning:
> >
> >commit c1ca352d371f724f7fb40f016abdb563aa85fe55
> >Author: Jason Wang <jasowang@redhat.com>
> >Date:   Tue Sep 27 15:48:10 2022 +0800
> >
> >    vp_vdpa: support feature provisioning
> >
> >For example:
> >
> >vdpa dev add name dev1 mgmtdev pci/0000:02:00.0 device_features 0x300020000
>
> Sure. My intension was to make the testing possible on any virtio
> device.

It did that actually, vp_vdpa bridge virtio-pci device into vDPA bus
with mediation layer (like feature filtering etc). So it can only run
on top of standard virtio-pci device.

> Narrowing the testing for vpda would be limitting.

Unless you want to use other transport like virtio-mmio.

Thanks

>
>
> >
> >Thanks
> >
>

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

[Jiri Pirko]

Wed, Apr 17, 2024 at 06:37:30AM CEST, jasowang@redhat.com wrote:
>On Tue, Apr 16, 2024 at 5:37 PM Jiri Pirko <jiri@resnulli.us> wrote:
>>
>> Tue, Apr 16, 2024 at 05:52:41AM CEST, jasowang@redhat.com wrote:
>> >On Tue, Apr 16, 2024 at 12:25 AM Jiri Pirko <jiri@resnulli.us> wrote:
>> >>
>> >> 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>
>> >> ---
>> >
>> >Note that this can be done already with vp_vdpa feature provisioning:
>> >
>> >commit c1ca352d371f724f7fb40f016abdb563aa85fe55
>> >Author: Jason Wang <jasowang@redhat.com>
>> >Date:   Tue Sep 27 15:48:10 2022 +0800
>> >
>> >    vp_vdpa: support feature provisioning
>> >
>> >For example:
>> >
>> >vdpa dev add name dev1 mgmtdev pci/0000:02:00.0 device_features 0x300020000
>>
>> Sure. My intension was to make the testing possible on any virtio
>> device.
>
>It did that actually, vp_vdpa bridge virtio-pci device into vDPA bus
>with mediation layer (like feature filtering etc). So it can only run
>on top of standard virtio-pci device.
>
>> Narrowing the testing for vpda would be limitting.
>
>Unless you want to use other transport like virtio-mmio.

Also, the goal is to test virtio_net emulated devices. There are couple
of implementation. Non-vdpa.


>
>Thanks
>
>>
>>
>> >
>> >Thanks
>> >
>>
>

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

[Jason Wang]

On Wed, Apr 17, 2024 at 3:23 PM Jiri Pirko <jiri@resnulli.us> wrote:
>
> Wed, Apr 17, 2024 at 06:37:30AM CEST, jasowang@redhat.com wrote:
> >On Tue, Apr 16, 2024 at 5:37 PM Jiri Pirko <jiri@resnulli.us> wrote:
> >>
> >> Tue, Apr 16, 2024 at 05:52:41AM CEST, jasowang@redhat.com wrote:
> >> >On Tue, Apr 16, 2024 at 12:25 AM Jiri Pirko <jiri@resnulli.us> wrote:
> >> >>
> >> >> 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>
> >> >> ---
> >> >
> >> >Note that this can be done already with vp_vdpa feature provisioning:
> >> >
> >> >commit c1ca352d371f724f7fb40f016abdb563aa85fe55
> >> >Author: Jason Wang <jasowang@redhat.com>
> >> >Date:   Tue Sep 27 15:48:10 2022 +0800
> >> >
> >> >    vp_vdpa: support feature provisioning
> >> >
> >> >For example:
> >> >
> >> >vdpa dev add name dev1 mgmtdev pci/0000:02:00.0 device_features 0x300020000
> >>
> >> Sure. My intension was to make the testing possible on any virtio
> >> device.
> >
> >It did that actually, vp_vdpa bridge virtio-pci device into vDPA bus
> >with mediation layer (like feature filtering etc). So it can only run
> >on top of standard virtio-pci device.
> >
> >> Narrowing the testing for vpda would be limitting.
> >
> >Unless you want to use other transport like virtio-mmio.
>
> Also, the goal is to test virtio_net emulated devices.
> There are couple
> of implementation. Non-vdpa.

So what I want to say is, vp_vdpa works for all types of virtio-pci
devices no matter if it is emulated or hardware.

Thanks

>
>
> >
> >Thanks
> >
> >>
> >>
> >> >
> >> >Thanks
> >> >
> >>
> >
>

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

[Jiri Pirko]

Thu, Apr 18, 2024 at 02:59:41AM CEST, jasowang@redhat.com wrote:
>On Wed, Apr 17, 2024 at 3:23 PM Jiri Pirko <jiri@resnulli.us> wrote:
>>
>> Wed, Apr 17, 2024 at 06:37:30AM CEST, jasowang@redhat.com wrote:
>> >On Tue, Apr 16, 2024 at 5:37 PM Jiri Pirko <jiri@resnulli.us> wrote:
>> >>
>> >> Tue, Apr 16, 2024 at 05:52:41AM CEST, jasowang@redhat.com wrote:
>> >> >On Tue, Apr 16, 2024 at 12:25 AM Jiri Pirko <jiri@resnulli.us> wrote:
>> >> >>
>> >> >> 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>
>> >> >> ---
>> >> >
>> >> >Note that this can be done already with vp_vdpa feature provisioning:
>> >> >
>> >> >commit c1ca352d371f724f7fb40f016abdb563aa85fe55
>> >> >Author: Jason Wang <jasowang@redhat.com>
>> >> >Date:   Tue Sep 27 15:48:10 2022 +0800
>> >> >
>> >> >    vp_vdpa: support feature provisioning
>> >> >
>> >> >For example:
>> >> >
>> >> >vdpa dev add name dev1 mgmtdev pci/0000:02:00.0 device_features 0x300020000
>> >>
>> >> Sure. My intension was to make the testing possible on any virtio
>> >> device.
>> >
>> >It did that actually, vp_vdpa bridge virtio-pci device into vDPA bus
>> >with mediation layer (like feature filtering etc). So it can only run
>> >on top of standard virtio-pci device.
>> >
>> >> Narrowing the testing for vpda would be limitting.
>> >
>> >Unless you want to use other transport like virtio-mmio.
>>
>> Also, the goal is to test virtio_net emulated devices.
>> There are couple
>> of implementation. Non-vdpa.
>
>So what I want to say is, vp_vdpa works for all types of virtio-pci
>devices no matter if it is emulated or hardware.

Sure, but I wanted to have a simple generic way, working on all virtio
devices, even the ones backed by a different transport, and without need
of extra vdpa layer.


>
>Thanks
>
>>
>>
>> >
>> >Thanks
>> >
>> >>
>> >>
>> >> >
>> >> >Thanks
>> >> >
>> >>
>> >
>>
>