On Tue, Sep 17, 2024 at 09:05:34AM +0200, Albert Esteve wrote: > On Mon, Sep 16, 2024 at 7:57 PM Stefan Hajnoczi <stefa...@redhat.com> wrote: > > > This patch series could use tests. The first two patches seem broken and > > testing would have revealed that the memory allocation and pointers are > > not quite right. > > > > My bad. Previous version of the patch I did test with a device that I've > been working on that utilizes the map/unmap messages. But I skipped it > for this one. I will test it for any coming versions. > > > > > > One testing approach is to write a test device using libvhost-user that > > exposes VIRTIO Shared Memory Regions, launch QEMU in qtest mode with > > --device vhost-user-device, and then use the qtest API to enumerate and > > access the VIRTIO Shared Memory Regions. Unfortunately this involves > > writing quite a bit of test code. I can explain it in more detail if you > > want. > > > > If we want to have tests covering the feature within qemu, I can try > to do this. I'm also more comfortable if there are tests in place. > As I mentioned, before this patch I was verifying with an > external device myself.
Good, automated tests will continue to be protected by tests after it is merged. QEMU's qtest framework (tests/qtest/) launches QEMU in the special qtest mode where the guest does not execute CPU instructions. The test case can send commands like reading and writing guest RAM and hardware registers so it can remote-control QEMU as if it were a running guest. https://www.qemu.org/docs/master/devel/testing/qtest.html qtest is low-level but there are VIRTIO qtest APIs that offer something similar to a VIRTIO driver API. You could extend that API to support VIRTIO Shared Memory Regions over virtio-pci (tests/qtest/libqos/virtio-pci.c). A vhost-user device is also required. You could implement a dummy device with libvhost-user that has a few VIRTIO Shared Memory Regions and nothing else (no virtqueues, etc). The dummy device would create a shared memory file descriptor and send the SHMEM_MAP message. Then a qtest test case can be written that launches the dummy vhost-user device and QEMU with --device vhost-user-device. Using the qtest VIRTIO API you can initialize the device, enumerate VIRTIO Shared Memory Regions (using the new qtest API you added), and test that loading/storing to the VIRTIO Shared Memory Region works. It would also be possible to test more advanced cases like 256 VIRTIO Shared Memory Regions, skipping regions with 0 size, MAP/UNMAP sequences including rejecting partial UNMAP and overlapping MAP, etc. Stefan
signature.asc
Description: PGP signature
