| Message ID | 20240412151314.3365034-1-jiri@resnulli.us (mailing list archive) |
|---|---|
| Headers | show |
| Series | selftests: virtio_net: introduce initial testing infrastructure | expand |
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.
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.
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 ?
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.
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
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 >
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