python/Pipfile.lock | 66 +++++++++++++---------- python/qemu/aqmp/legacy.py | 3 ++ python/qemu/aqmp/protocol.py | 41 ++++++++++++-- python/qemu/aqmp/qmp_client.py | 4 +- python/qemu/machine/machine.py | 45 +++++++++++++--- python/setup.cfg | 2 +- tests/qemu-iotests/tests/mirror-top-perms | 3 +- 7 files changed, 123 insertions(+), 41 deletions(-)
The following changes since commit 47cc1a3655135b89fa75c2824fbddd29df874612: Merge remote-tracking branch 'remotes/kwolf-gitlab/tags/for-upstream' into staging (2022-02-01 19:48:15 +0000) are available in the Git repository at: https://gitlab.com/jsnow/qemu.git tags/python-pull-request for you to fetch changes up to b0b662bb2b340d63529672b5bdae596a6243c4d0: python/aqmp: add socket bind step to legacy.py (2022-02-02 14:12:22 -0500) ---------------------------------------------------------------- Python patches Peter: I expect this to address the iotest 040,041 failures you observed on NetBSD. If it doesn't, let me know. ---------------------------------------------------------------- John Snow (4): python/aqmp: Fix negotiation with pre-"oob" QEMU python/machine: raise VMLaunchFailure exception from launch() python: upgrade mypy to 0.780 python/aqmp: add socket bind step to legacy.py python/Pipfile.lock | 66 +++++++++++++---------- python/qemu/aqmp/legacy.py | 3 ++ python/qemu/aqmp/protocol.py | 41 ++++++++++++-- python/qemu/aqmp/qmp_client.py | 4 +- python/qemu/machine/machine.py | 45 +++++++++++++--- python/setup.cfg | 2 +- tests/qemu-iotests/tests/mirror-top-perms | 3 +- 7 files changed, 123 insertions(+), 41 deletions(-) -- 2.31.1
On Thu, 3 Feb 2022 at 01:59, John Snow <jsnow@redhat.com> wrote:
>
> The following changes since commit 47cc1a3655135b89fa75c2824fbddd29df874612:
>
> Merge remote-tracking branch 'remotes/kwolf-gitlab/tags/for-upstream' into staging (2022-02-01 19:48:15 +0000)
>
> are available in the Git repository at:
>
> https://gitlab.com/jsnow/qemu.git tags/python-pull-request
>
> for you to fetch changes up to b0b662bb2b340d63529672b5bdae596a6243c4d0:
>
> python/aqmp: add socket bind step to legacy.py (2022-02-02 14:12:22 -0500)
>
> ----------------------------------------------------------------
> Python patches
>
> Peter: I expect this to address the iotest 040,041 failures you observed
> on NetBSD. If it doesn't, let me know.
I still see this one, which is different from the 040,041 stuff,
and where 'make check' is for some reason giving a lot less useful
detail. (This is a prexisting intermittent from before this patchset).
[etc]
▶ 175/704 /io/channel/pipe/sync
OK
▶ 175/704 /io/channel/pipe/async
OK
175/704 qemu:unit / test-io-channel-file
OK 0.11s 5 subtests passed
177/704 qemu:unit / test-io-channel-tls
RUNNING
>>> G_TEST_BUILDDIR=/home/qemu/qemu-test.yiYr4m/build/tests/unit MALLOC_PERTURB_=5 G_TEST_SRCDIR=/home/qemu/qemu-test.yiYr4m/src/tests/unit /home/
qemu/qemu-test.yiYr4m/build/tests/unit/test-io-channel-tls --tap -k
▶ 176/704 /io/channel/socket/ipv4-sync
OK
▶ 176/704 /io/channel/socket/ipv4-async
OK
▶ 176/704 /io/channel/socket/ipv4-fd
OK
▶ 176/704 /io/channel/socket/ipv6-sync
OK
▶ 176/704 /io/channel/socket/ipv6-async
OK
▶ 176/704 /io/channel/socket/unix-sync
OK
▶ 176/704 /io/channel/socket/unix-async
OK
▶ 176/704 /io/channel/socket/unix-fd-pass
OK
▶ 176/704 /io/channel/socket/unix-listen-cleanup
OK
176/704 qemu:unit / test-io-channel-socket
OK 0.13s 9 subtests passed
▶ 1/1 qcow2 qsd-jobs OK
1/1 qemu:block / qemu-iotests qcow2 ERROR 243.14s exit status 1
178/704 qemu:unit / test-io-task
RUNNING
>>> G_TEST_BUILDDIR=/home/qemu/qemu-test.yiYr4m/build/tests/unit MALLOC_PERTURB_=194 G_TEST_SRCDIR=/home/qemu/qemu-test.yiYr4m/src/tests/unit /hom
e/qemu/qemu-test.yiYr4m/build/tests/unit/test-io-task --tap -k
▶ 147/704 /bdrv-drain/blockjob/iothread/error/drain_subtree
OK
Summary of Failures:
1/1 qemu:block / qemu-iotests qcow2 ERROR 243.14s exit status 1
Ok: 0
Expected Fail: 0
Fail: 1
Unexpected Pass: 0
Skipped: 0
Timeout: 0
Full log written to /home/qemu/qemu-test.yiYr4m/build/meson-logs/iotestslog.txt
▶ 147/704 /bdrv-drain/deletion/drain
OK
▶ 178/704 /crypto/task/complete
OK
▶ 178/704 /crypto/task/datafree
OK
[etc]
thanks
-- PMM
On Thu, Feb 3, 2022, 11:20 AM Peter Maydell <peter.maydell@linaro.org> wrote: > On Thu, 3 Feb 2022 at 01:59, John Snow <jsnow@redhat.com> wrote: > > > > The following changes since commit > 47cc1a3655135b89fa75c2824fbddd29df874612: > > > > Merge remote-tracking branch 'remotes/kwolf-gitlab/tags/for-upstream' > into staging (2022-02-01 19:48:15 +0000) > > > > are available in the Git repository at: > > > > https://gitlab.com/jsnow/qemu.git tags/python-pull-request > > > > for you to fetch changes up to b0b662bb2b340d63529672b5bdae596a6243c4d0: > > > > python/aqmp: add socket bind step to legacy.py (2022-02-02 14:12:22 > -0500) > > > > ---------------------------------------------------------------- > > Python patches > > > > Peter: I expect this to address the iotest 040,041 failures you observed > > on NetBSD. If it doesn't, let me know. > > I still see this one, which is different from the 040,041 stuff, > and where 'make check' is for some reason giving a lot less useful > detail. (This is a prexisting intermittent from before this patchset). > I'm assuming there's less detail because of the meson test-runner doing some io redirection into the logfile. [etc] > ▶ 175/704 /io/channel/pipe/sync > OK > ▶ 175/704 /io/channel/pipe/async > OK > 175/704 qemu:unit / test-io-channel-file > OK 0.11s 5 subtests passed > > 177/704 qemu:unit / test-io-channel-tls > RUNNING > >>> G_TEST_BUILDDIR=/home/qemu/qemu-test.yiYr4m/build/tests/unit > MALLOC_PERTURB_=5 G_TEST_SRCDIR=/home/qemu/qemu-test.yiYr4m/src/tests/unit > /home/ > qemu/qemu-test.yiYr4m/build/tests/unit/test-io-channel-tls --tap -k > ▶ 176/704 /io/channel/socket/ipv4-sync > OK > ▶ 176/704 /io/channel/socket/ipv4-async > OK > ▶ 176/704 /io/channel/socket/ipv4-fd > OK > ▶ 176/704 /io/channel/socket/ipv6-sync > OK > ▶ 176/704 /io/channel/socket/ipv6-async > OK > ▶ 176/704 /io/channel/socket/unix-sync > OK > ▶ 176/704 /io/channel/socket/unix-async > OK > ▶ 176/704 /io/channel/socket/unix-fd-pass > OK > ▶ 176/704 /io/channel/socket/unix-listen-cleanup > OK > 176/704 qemu:unit / test-io-channel-socket > OK 0.13s 9 subtests passed > > ▶ 1/1 qcow2 qsd-jobs OK > 1/1 qemu:block / qemu-iotests qcow2 ERROR 243.14s exit status 1 > > 178/704 qemu:unit / test-io-task > RUNNING > >>> G_TEST_BUILDDIR=/home/qemu/qemu-test.yiYr4m/build/tests/unit > MALLOC_PERTURB_=194 > G_TEST_SRCDIR=/home/qemu/qemu-test.yiYr4m/src/tests/unit /hom > e/qemu/qemu-test.yiYr4m/build/tests/unit/test-io-task --tap -k > ▶ 147/704 /bdrv-drain/blockjob/iothread/error/drain_subtree > OK > > Summary of Failures: > > 1/1 qemu:block / qemu-iotests qcow2 ERROR 243.14s exit status 1 > > > Ok: 0 > Expected Fail: 0 > Fail: 1 > Unexpected Pass: 0 > Skipped: 0 > Timeout: 0 > > Full log written to > /home/qemu/qemu-test.yiYr4m/build/meson-logs/iotestslog.txt > ▶ 147/704 /bdrv-drain/deletion/drain > OK > ▶ 178/704 /crypto/task/complete > OK > ▶ 178/704 /crypto/task/datafree > OK > [etc] > > thanks > -- PMM > Any chance of seeing that meson-logs/iotestslog.txt file? >
On Thu, 3 Feb 2022 at 16:38, John Snow <jsnow@redhat.com> wrote: > On Thu, Feb 3, 2022, 11:20 AM Peter Maydell <peter.maydell@linaro.org> wrote: >> Summary of Failures: >> >> 1/1 qemu:block / qemu-iotests qcow2 ERROR 243.14s exit status 1 >> >> >> Ok: 0 >> Expected Fail: 0 >> Fail: 1 >> Unexpected Pass: 0 >> Skipped: 0 >> Timeout: 0 >> >> Full log written to /home/qemu/qemu-test.yiYr4m/build/meson-logs/iotestslog.txt >> ▶ 147/704 /bdrv-drain/deletion/drain >> OK >> ▶ 178/704 /crypto/task/complete >> OK >> ▶ 178/704 /crypto/task/datafree >> OK >> [etc] > Any chance of seeing that meson-logs/iotestslog.txt file? Sorry, no. The VM runs, and it produces output to stdout, and then it goes away again. The test cases and test harnesses *must* output to standard output any information that might be useful for diagnosing problems. The same scenario applies for the gitlab CI jobs -- all we get is the job's output. -- PMM
On Thu, Feb 3, 2022 at 11:52 AM Peter Maydell <peter.maydell@linaro.org> wrote: > > On Thu, 3 Feb 2022 at 16:38, John Snow <jsnow@redhat.com> wrote: > > > On Thu, Feb 3, 2022, 11:20 AM Peter Maydell <peter.maydell@linaro.org> wrote: > >> Summary of Failures: > >> > >> 1/1 qemu:block / qemu-iotests qcow2 ERROR 243.14s exit status 1 I'm not too familiar with this new test runner, yet. (Is this error even anything to do with the python lib? I guess I can't rule it out...) I just got a clean run of 'make vm-build-netbsd', so I'm using that output as reference and making some guesses. If I search the output for 'qcow2', I see the following output (with possibly many lines between each hit): 1/1 qemu:block / qemu-iotests qcow2 RUNNING >>> MALLOC_PERTURB_=205 PYTHON=/usr/pkg/bin/python3.7 /bin/sh /home/qemu/qemu-test.lj6FNa/build/../src/tests/qemu-iotests/../check-block.sh qcow2 ▶ 1/1 qcow2 001 OK ▶ 1/1 qcow2 002 OK ▶ 1/1 qcow2 004 OK ... and so on and so forth ... ▶ 1/1 qcow2 299 OK ▶ 1/1 qcow2 313 SKIP ▶ 1/1 qcow2 nbd-qemu-allocation SKIP ▶ 1/1 qcow2 qsd-jobs OK 1/1 qemu:block / qemu-iotests qcow2 OK 176.35s 74 subtests passed I tried modifying 040 to fail on purpose, and I see: ▶ 1/1 qcow2 039 OK ▶ 1/1 qcow2 040 FAIL ▶ 1/1 qcow2 041 OK [...] ▶ 1/1 qcow2 nbd-qemu-allocation OK ▶ 1/1 qcow2 qsd-jobs OK 1/1 qemu:block / qemu-iotests qcow2 ERROR 106.06s exit status 1 Summary of Failures: 1/1 qemu:block / qemu-iotests qcow2 ERROR 106.06s exit status 1 I don't think I see it on the output you mailed, but can you point out which test is failing, at least? Grepping for 'FAIL' should be helpful. --js
On Thu, 3 Feb 2022 at 23:22, John Snow <jsnow@redhat.com> wrote: > > On Thu, Feb 3, 2022 at 11:52 AM Peter Maydell <peter.maydell@linaro.org> wrote: > > > > On Thu, 3 Feb 2022 at 16:38, John Snow <jsnow@redhat.com> wrote: > > > > > On Thu, Feb 3, 2022, 11:20 AM Peter Maydell <peter.maydell@linaro.org> wrote: > > >> Summary of Failures: > > >> > > >> 1/1 qemu:block / qemu-iotests qcow2 ERROR 243.14s exit status 1 > > I'm not too familiar with this new test runner, yet. (Is this error > even anything to do with the python lib? I guess I can't rule it > out...) > I just got a clean run of 'make vm-build-netbsd', so I'm using that > output as reference and making some guesses. Rerunning on the netbsd VM with Paolo's "revert the iotests conversion" patch, here's the output from a failing run, where iotest 041 failed: TEST iotest-qcow2: 041 [fail] QEMU -- "/home/qemu/qemu-test.Kywnb7/build/tests/qemu-iotests/../../qemu-system-aarch64" -nodefaults -display none -accel qtest -machine virt QEMU_IMG -- "/home/qemu/qemu-test.Kywnb7/build/tests/qemu-iotests/../../qemu-img" QEMU_IO -- "/home/qemu/qemu-test.Kywnb7/build/tests/qemu-iotests/../../qemu-io" --cache writeback --aio threads -f qcow2 QEMU_NBD -- "/home/qemu/qemu-test.Kywnb7/build/tests/qemu-iotests/../../qemu-nbd" IMGFMT -- qcow2 IMGPROTO -- file PLATFORM -- NetBSD/amd64 localhost 9.2 TEST_DIR -- /home/qemu/qemu-test.Kywnb7/build/tests/qemu-iotests/scratch SOCK_DIR -- /tmp/tmp6fiu68sr GDB_OPTIONS -- VALGRIND_QEMU -- PRINT_QEMU_OUTPUT -- --- /home/qemu/qemu-test.Kywnb7/src/tests/qemu-iotests/041.out +++ 041.out.bad @@ -1,5 +1,44 @@ -........................................................................................................... +........................................ERROR:qemu.aqmp.qmp_client.qemu-14411:Failed to establish connection: concurrent.futures._base.CancelledError +E.................................................................. +====================================================================== +ERROR: test_mirror_to_self (__main__.TestSingleBlockdev) +---------------------------------------------------------------------- +Traceback (most recent call last): + File "/home/qemu/qemu-test.Kywnb7/src/python/qemu/machine/machine.py", line 428, in launch + self._launch() + File "/home/qemu/qemu-test.Kywnb7/src/python/qemu/machine/machine.py", line 467, in _launch + self._post_launch() + File "/home/qemu/qemu-test.Kywnb7/src/python/qemu/machine/qtest.py", line 147, in _post_launch + super()._post_launch() + File "/home/qemu/qemu-test.Kywnb7/src/python/qemu/machine/machine.py", line 369, in _post_launch + self._qmp.accept(self._qmp_timer) + File "/home/qemu/qemu-test.Kywnb7/src/python/qemu/aqmp/legacy.py", line 95, in accept + timeout + File "/home/qemu/qemu-test.Kywnb7/src/python/qemu/aqmp/legacy.py", line 68, in _sync + asyncio.wait_for(future, timeout=timeout) + File "/usr/pkg/lib/python3.7/asyncio/base_events.py", line 587, in run_until_complete + return future.result() + File "/usr/pkg/lib/python3.7/asyncio/tasks.py", line 449, in wait_for + raise futures.TimeoutError() +concurrent.futures._base.TimeoutError + +The above exception was the direct cause of the following exception: + +Traceback (most recent call last): + File "/home/qemu/qemu-test.Kywnb7/src/tests/qemu-iotests/041", line 233, in setUp + TestSingleDrive.setUp(self) + File "/home/qemu/qemu-test.Kywnb7/src/tests/qemu-iotests/041", line 54, in setUp + self.vm.launch() + File "/home/qemu/qemu-test.Kywnb7/src/python/qemu/machine/machine.py", line 445, in launch + ) from exc +qemu.machine.machine.VMLaunchFailure: TimeoutError + Exit code: 1 + Command: /home/qemu/qemu-test.Kywnb7/build/tests/qemu-iotests/../../qemu-system-aarch64 -display none -vga none -chardev socket,id=mon,path=/tmp/tmp6fiu68sr/qemu-14411-monitor.sock -mon chardev=mon,mode=control -qtest unix:path=/tmp/tmp6fiu68sr/qemu-14411-qtest.sock -accel qtest -nodefaults -display none -accel qtest -machine virt -drive if=virtio,id=drive0,file=/home/qemu/qemu-test.Kywnb7/build/tests/qemu-iotests/scratch/test.img,format=qcow2,cache=writeback,aio=threads,node-name=top,backing.node-name=base + Output: qemu-system-aarch64: -chardev socket,id=mon,path=/tmp/tmp6fiu68sr/qemu-14411-monitor.sock: Failed to connect to '/tmp/tmp6fiu68sr/qemu-14411-monitor.sock': Connection refused + + + ---------------------------------------------------------------------- Ran 107 tests -OK +FAILED (errors=1) thanks -- PMM
On Tue, Feb 8, 2022 at 9:40 AM Peter Maydell <peter.maydell@linaro.org> wrote: > > On Thu, 3 Feb 2022 at 23:22, John Snow <jsnow@redhat.com> wrote: > > > > On Thu, Feb 3, 2022 at 11:52 AM Peter Maydell <peter.maydell@linaro.org> wrote: > > > > > > On Thu, 3 Feb 2022 at 16:38, John Snow <jsnow@redhat.com> wrote: > > > > > > > On Thu, Feb 3, 2022, 11:20 AM Peter Maydell <peter.maydell@linaro.org> wrote: > > > >> Summary of Failures: > > > >> > > > >> 1/1 qemu:block / qemu-iotests qcow2 ERROR 243.14s exit status 1 > > > > I'm not too familiar with this new test runner, yet. (Is this error > > even anything to do with the python lib? I guess I can't rule it > > out...) > > I just got a clean run of 'make vm-build-netbsd', so I'm using that > > output as reference and making some guesses. > > Rerunning on the netbsd VM with Paolo's "revert the iotests > conversion" patch, here's the output from a failing run, where > iotest 041 failed: > > TEST iotest-qcow2: 041 [fail] > QEMU -- > "/home/qemu/qemu-test.Kywnb7/build/tests/qemu-iotests/../../qemu-system-aarch64" > -nodefaults -display none -accel qtest -machine virt > QEMU_IMG -- > "/home/qemu/qemu-test.Kywnb7/build/tests/qemu-iotests/../../qemu-img" > QEMU_IO -- > "/home/qemu/qemu-test.Kywnb7/build/tests/qemu-iotests/../../qemu-io" > --cache writeback --aio threads -f qcow2 > QEMU_NBD -- > "/home/qemu/qemu-test.Kywnb7/build/tests/qemu-iotests/../../qemu-nbd" > IMGFMT -- qcow2 > IMGPROTO -- file > PLATFORM -- NetBSD/amd64 localhost 9.2 > TEST_DIR -- /home/qemu/qemu-test.Kywnb7/build/tests/qemu-iotests/scratch > SOCK_DIR -- /tmp/tmp6fiu68sr > GDB_OPTIONS -- > VALGRIND_QEMU -- > PRINT_QEMU_OUTPUT -- > > --- /home/qemu/qemu-test.Kywnb7/src/tests/qemu-iotests/041.out > +++ 041.out.bad > @@ -1,5 +1,44 @@ > -........................................................................................................... > +........................................ERROR:qemu.aqmp.qmp_client.qemu-14411:Failed > to establish connection: concurrent.futures._base.CancelledError > +E.................................................................. > +====================================================================== > +ERROR: test_mirror_to_self (__main__.TestSingleBlockdev) > +---------------------------------------------------------------------- > +Traceback (most recent call last): > + File "/home/qemu/qemu-test.Kywnb7/src/python/qemu/machine/machine.py", > line 428, in launch > + self._launch() > + File "/home/qemu/qemu-test.Kywnb7/src/python/qemu/machine/machine.py", > line 467, in _launch > + self._post_launch() > + File "/home/qemu/qemu-test.Kywnb7/src/python/qemu/machine/qtest.py", > line 147, in _post_launch > + super()._post_launch() > + File "/home/qemu/qemu-test.Kywnb7/src/python/qemu/machine/machine.py", > line 369, in _post_launch > + self._qmp.accept(self._qmp_timer) > + File "/home/qemu/qemu-test.Kywnb7/src/python/qemu/aqmp/legacy.py", > line 95, in accept > + timeout > + File "/home/qemu/qemu-test.Kywnb7/src/python/qemu/aqmp/legacy.py", > line 68, in _sync > + asyncio.wait_for(future, timeout=timeout) > + File "/usr/pkg/lib/python3.7/asyncio/base_events.py", line 587, in > run_until_complete > + return future.result() > + File "/usr/pkg/lib/python3.7/asyncio/tasks.py", line 449, in wait_for > + raise futures.TimeoutError() > +concurrent.futures._base.TimeoutError > + > +The above exception was the direct cause of the following exception: > + > +Traceback (most recent call last): > + File "/home/qemu/qemu-test.Kywnb7/src/tests/qemu-iotests/041", line > 233, in setUp > + TestSingleDrive.setUp(self) > + File "/home/qemu/qemu-test.Kywnb7/src/tests/qemu-iotests/041", line > 54, in setUp > + self.vm.launch() > + File "/home/qemu/qemu-test.Kywnb7/src/python/qemu/machine/machine.py", > line 445, in launch > + ) from exc > +qemu.machine.machine.VMLaunchFailure: TimeoutError > + Exit code: 1 > + Command: > /home/qemu/qemu-test.Kywnb7/build/tests/qemu-iotests/../../qemu-system-aarch64 > -display none -vga none -chardev > socket,id=mon,path=/tmp/tmp6fiu68sr/qemu-14411-monitor.sock -mon > chardev=mon,mode=control -qtest > unix:path=/tmp/tmp6fiu68sr/qemu-14411-qtest.sock -accel qtest > -nodefaults -display none -accel qtest -machine virt -drive > if=virtio,id=drive0,file=/home/qemu/qemu-test.Kywnb7/build/tests/qemu-iotests/scratch/test.img,format=qcow2,cache=writeback,aio=threads,node-name=top,backing.node-name=base > + Output: qemu-system-aarch64: -chardev > socket,id=mon,path=/tmp/tmp6fiu68sr/qemu-14411-monitor.sock: Failed to > connect to '/tmp/tmp6fiu68sr/qemu-14411-monitor.sock': Connection > refused > + > + > + > ---------------------------------------------------------------------- > Ran 107 tests > > -OK > +FAILED (errors=1) > > > thanks > -- PMM > Just so I don't leave this thread hanging, I filed a GitLab issue and I'm working on it, but this one isn't as quick to solve as the other. https://gitlab.com/qemu-project/qemu/-/issues/874 --js
On Tue, 15 Feb 2022 at 17:46, John Snow <jsnow@redhat.com> wrote: > Just so I don't leave this thread hanging, I filed a GitLab issue and > I'm working on it, but this one isn't as quick to solve as the other. > > https://gitlab.com/qemu-project/qemu/-/issues/874 Is there anything particular to NetBSD that means it happens more often there, or is it just random luck that we hit the race there and haven't seen it elsewhere ? -- PMM
On Tue, Feb 15, 2022 at 1:01 PM Peter Maydell <peter.maydell@linaro.org> wrote: > > On Tue, 15 Feb 2022 at 17:46, John Snow <jsnow@redhat.com> wrote: > > Just so I don't leave this thread hanging, I filed a GitLab issue and > > I'm working on it, but this one isn't as quick to solve as the other. > > > > https://gitlab.com/qemu-project/qemu/-/issues/874 > > Is there anything particular to NetBSD that means it happens > more often there, or is it just random luck that we hit > the race there and haven't seen it elsewhere ? > > -- PMM Complete random luck, something jostled loose by the scheduler. I need to change the interface in the async library entirely to make the process more granular -- We don't need the granularity in a truly async mode, but the sync wrapper that allows the existing iotests corpus to use the library in a synchronous manner *requires* a more granular connection API, so I have to write one. It's in progress, it just might be a few more days; verifying and testing the error pathways has been slow work. (In detail: python's asyncio.create_unix_server() call combines bind() + listen() + accept() into a single discrete step. A synchronous client, though, needs to have a reprieve from all of those blocking steps to launch the QEMU process after listen() but before accept() so it can launch the QEMU process. I was able to pull the bind() step out, but the async listen() + accept() steps the way I initially wrote it are inseparable. Live and learn.) In the meantime, there *IS* a way to use the old library, but I don't think the environment variable in question is routed down into the VM tests. I can look at (as a very quick fix) amending the VM launcher to pass along that environment variable if it sees it set in the host environment -- that should get you on the old, tried-and-true library when you want it, and the test should pass. --js
On Thu, 3 Feb 2022 at 01:59, John Snow <jsnow@redhat.com> wrote: > > The following changes since commit 47cc1a3655135b89fa75c2824fbddd29df874612: > > Merge remote-tracking branch 'remotes/kwolf-gitlab/tags/for-upstream' into staging (2022-02-01 19:48:15 +0000) > > are available in the Git repository at: > > https://gitlab.com/jsnow/qemu.git tags/python-pull-request > > for you to fetch changes up to b0b662bb2b340d63529672b5bdae596a6243c4d0: > > python/aqmp: add socket bind step to legacy.py (2022-02-02 14:12:22 -0500) > > ---------------------------------------------------------------- > Python patches > > Peter: I expect this to address the iotest 040,041 failures you observed > on NetBSD. If it doesn't, let me know. > > ---------------------------------------------------------------- Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/7.0 for any user-visible changes. -- PMM
© 2016 - 2026 Red Hat, Inc.