aboutsummaryrefslogtreecommitdiff
path: root/scripts/qapi/parser.py
diff options
context:
space:
mode:
authorThomas Huth <thuth@redhat.com>2025-09-09 09:48:17 +0200
committerThomas Huth <thuth@redhat.com>2025-09-23 11:32:27 +0200
commit6096dfa6c5cedf1e4e9ae04b27fb238ef390047f (patch)
tree9569465ee8693979d93a17a9cae190cb7fb553a5 /scripts/qapi/parser.py
parentab8008b231e758e03c87c1c483c03afdd9c02e19 (diff)
downloadqemu-6096dfa6c5cedf1e4e9ae04b27fb238ef390047f.zip
qemu-6096dfa6c5cedf1e4e9ae04b27fb238ef390047f.tar.gz
qemu-6096dfa6c5cedf1e4e9ae04b27fb238ef390047f.tar.bz2
tests/functional/m68k: Use proper polling in the next-cube test
The next-cube tests currently sleep for 2 seconds to wait for the guest's display to come up with the expected results. That's bad since there is still a theoretical race left here, and since there are two subtests, the whole test takes more than 4 seconds this way. Looking at what the firmware does, there is a better way instead of blindly waiting for two seconds: The firmware is writing some values to the FPU registers during a test (and never touches them again afterwards, so we can be sure about the final values), so we can poll for the right values in those registers to know when we reached a state when the display is initialized for sure. We just have to also make sure to not look for text anymore that is only printed after the FPU test has been done by the guest firmware. This way the whole tests finishes in less than 1 second here, and there should be no race condition here anymore. Message-ID: <20250909074817.84661-1-thuth@redhat.com> Acked-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
Diffstat (limited to 'scripts/qapi/parser.py')
0 files changed, 0 insertions, 0 deletions