On Tue, Nov 09, 2021 at 08:10:34AM +0100, Thomas Huth wrote: > On 08/11/2021 14.00, Pierre Morel wrote: > > > > > > On 11/3/21 09:14, Thomas Huth wrote: > > > On 03/11/2021 08.56, Andrew Jones wrote: > > > > On Fri, Aug 27, 2021 at 12:17:19PM +0200, Pierre Morel wrote: > > > > > + > > > > > +#define VIRTIO_ID_PONG 30 /* virtio pong */ > > > > > > > > I take it this is a virtio test device that ping-pong's I/O. It sounds > > > > useful for other VIRTIO transports too. Can it be ported? Hmm, I can't > > > > find it in QEMU at all? > > > > > > I also wonder whether we could do testing with an existing device > > > instead? E.g. do a loopback with a virtio-serial device? Or use two > > > virtio-net devices, connect them to a QEMU hub and send a packet > > > from one device to the other? ... that would be a little bit more > > > complicated here, but would not require a PONG device upstream > > > first, so it could also be used for testing older versions of > > > QEMU... > > > > > > Thomas > > > > > > > > > > Yes having a dedicated device has the drawback that we need it in QEMU. > > On the other hand using a specific device, serial or network, wouldn't > > we get trapped with a reduce set of test possibilities? > > > > The idea was to have a dedicated test device, which could be flexible > > and extended to test all VIRTIO features, even the current > > implementation is yet far from it. > > Do you have anything in the works that could only be tested with a dedicated > test device? If not, I'd rather go with the loopback via virtio-net, I think > (you can peek into the s390-ccw bios sources to see how to send packets via > virtio-net, shouldn't be too hard to do, I think). > > The pong device could later be added on top for additional tests that are > not possible with virtio-net. And having some basic tests with virito-net > has also the advantage that the k-u-t work with QEMU binaries where the pong > device is not available, e.g. older versions and downstream versions that > only enable the bare minimum of devices to keep the attack surface small. > I'd also like to see the testdev we already have, qemu:chardev/testdev.c, get more functions, but I'm not sure virtio-serial will allow you to exercise all the virtio functionality that you'd like to. Thanks, drew