On Mon, 14 Nov 2022 at 14:06, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > On Sat, Nov 12, 2022 at 05:19:42PM +0100, Dmitry Vyukov wrote: > > I am looking for a test module that allows > > to create a transient virtio device that can be used to activate a virtio > > driver are communicate with it as if from the host. > > Does such thing exist already? > > Or how are virtio transports/drivers tested/fuzzed nowadays? > > > > Thanks > > Just coding it up in qemu is probably easiest. This is how we test > most things. This works for some testing scenarios, but has important downsides: - fixed number of global virtio devices, so tests are not hermetic/parallel and proper fuzzing is impossible - tests running inside of the kernel can't control the device behavior, so lots of scenarios are untestable/unfuzzable - not suitable for most CI/fuzzing systems that run in clouds (nested virt is very slow) - require special setup per test suite (not scalable for CI/fuzzing systems that test all of kernel) A better and flexible approach to stub devices is to implement them inside of the kernel and allow creation of new transient instances (e.g. /dev/net/tun). Such stubs allow proper fuzzing, allow self-contained tests, allow the test to control stub behavior and are compatible with all machines (cloud, physical hw). Is my understanding of how such in-kernel stub device can be implemented correct? A stub driver could create struct virtio_device and call register_virtio_device() directly skipping all of the bus/probing code. The virtio_device implementation will be parallel to virtio_mmio/pci and implement its own virtio_config_ops and notify/kick callback. This will allow us to test all of the virtio device drivers (console, balloon, virtio sound/gpu, etc), but not the virtio_mmio/pci nor the real probing code. Is there a reasonable way to also test virtio_mmio/pci/probing from within the kernel?
