Re: [PULL 00/23] 9p queue 2026-06-29

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Thursday, 2 July 2026 20:21:54 CEST Pierrick Bouvier wrote:
> Hi Christian,
> 
> On 7/1/2026 9:20 AM, Christian Schoenebeck wrote:
> > On Tuesday, 30 June 2026 09:28:48 CEST Pierrick Bouvier wrote:
> >> Hi Christian,
> > 
> > Hi Pierrick,
> > 
> >> This series brought a test regression:
> >> $ ./build/pyvenv/bin/meson test -C build \
> >> --setup thorough --print-errorlogs \
> >> qemu:qtest-aarch64/qos-test
> >> ...
> >> ERROR:../tests/qtest/libqos/virtio-9p-client.c:280:v9fs_req_recv:
> >> assertion failed (hdr.id == id): (7 == 121)
> >> 
> >> It seems to come test added in patch 19
> >> "tests/9p: add 3 xattr FID limit test cases (synth fs driver)"
> >> This test runs only with slow setup, so I suspect it never worked and
> >> was never ran.
> > 
> > Of course I ran these slow tests.
> 
> I should have added "in our CI" sorry. I'm sure you developed, tested
> and ran those yourself.
> 
> > I intentionally registered these tests as "slow" tests as they take a long
> > time to complete and QEMU tests being notorious on exceeding the overall
> > CI
> > timeout limit. So these tests are exempted from running in the official CI
> > pipeline, but not from mine.
> > 
> > I just reran them with latest master head. However I am unable to
> > reproduce
> > your reported test error so far.
> > 
> > You cropped the output too aggressively. I need to know:
> > 
> > - Which test exactly failed? (especially whether it's really a synth
> > backend> 
> >   or a local backend test that failed)
>
> That's the complete log from the command given above.
> Note: disk is not full, but the error "no space left on device" is very
> weird.

OK, I was able to reproduce the test error. Root cause is that ext4 without 
ea_inode enabled is limited to ~4KB per xattr block. I'll prepare a patch.

For the next time: please note that the most important information is always 
the name of the test case that failed! There are several ways to run the 
tests. In the way you ran them, the name of the failed test is printed 
*before* the stderr block:

...
# slow test /aarch64/virt/generic-pcihost/pci-bus-generic/pci-bus/virtio-9p-
pci/virtio-9p/virtio-9p-tests/local/deep_absolute_path executed in 1.63 secs
# Start of xattr_limit tests
# starting QEMU: exec ./qemu-system-aarch64 -qtest unix:/tmp/qtest-22413.sock 
-qtest-log /dev/null -chardev socket,path=/tmp/qtest-22413.qmp,id=char0 -mo
n chardev=char0,mode=control -display none -audio none -run-with exit-with-
parent=on -M virt, -cpu max -fsdev local,id=fsdev0,path='/src/bee/qemu/build/q
test-9p-local-KKOMR3',security_model=mapped-xattr -device virtio-9p-
pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest  -accel qtest
not ok /aarch64/virt/generic-pcihost/pci-bus-generic/pci-bus/virtio-9p-pci/
virtio-9p/virtio-9p-tests/local/xattr_limit/default - ERROR:../tests/qtest/lib
qos/virtio-9p-client.c:280:v9fs_req_recv: assertion failed (hdr.id == id): (7 
== 121)
Bail out!
----------------------------------- stderr -----------------------------------
...

So here the failing test name was /aarch64/virt/generic-pcihost/pci-bus-
generic/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/xattr_limit/
default

Independent of this particular issue here, I wonder whether there is some way 
to register a test such that it won't break other people's test pipeline. 
Because these "local" backend xattr tests are sensible on underlying host 
capabilities. They are useful for me, but that should not mean to stop the 
world just because an unrelated test environment is missing a capability.

/Christian