[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

regression on s390: was Re: [PULL 37/40] monitor: Tidy up find_device_st

From: Christian Borntraeger
Subject: regression on s390: was Re: [PULL 37/40] monitor: Tidy up find_device_state()
Date: Mon, 18 Oct 2021 12:08:56 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0

Am 15.10.21 um 21:15 schrieb Richard Henderson:
On 10/15/21 4:08 AM, Christian Borntraeger wrote:

Am 13.10.21 um 11:07 schrieb Paolo Bonzini:
From: Markus Armbruster <armbru@redhat.com>

Commit 6287d827d4 "monitor: allow device_del to accept QOM paths"
extended find_device_state() to accept QOM paths in addition to qdev
IDs.  This added a checked conversion to TYPE_DEVICE at the end, which
duplicates the check done for the qdev ID case earlier, except it sets
a *different* error: GenericError "ID is not a hotpluggable device"
when passed a QOM path, and DeviceNotFound "Device 'ID' not found"
when passed a qdev ID.  Fortunately, the latter won't happen as long
as we add only devices to /machine/peripheral/.

Earlier, commit b6cc36abb2 "qdev: device_del: Search for to be
unplugged device in 'peripheral' container" rewrote the lookup by qdev
ID to use QOM instead of qdev_find_recursive(), so it can handle
buss-less devices.  It does so by constructing an absolute QOM path.
Works, but object_resolve_path_component() is easier.  Switching to it
also gets rid of the unclean duplication described above.

While there, avoid converting to TYPE_DEVICE twice, first to check
whether it's possible, and then for real.

This one broke qemu iotest 280 on s390:

280   fail       [13:06:19] [13:06:19]   0.3s   (last: 0.3s)  output mismatch 
(see 280.out.bad)
--- /home/cborntra/REPOS/qemu/tests/qemu-iotests/280.out
+++ 280.out.bad
@@ -37,14 +37,14 @@
  === Resume the VM and simulate a write request ===
  {"execute": "cont", "arguments": {}}
  {"return": {}}
-{"return": ""}
+{"return": "Error: Device 'vda/virtio-backend' not found\r\n"}

Hmm, this test doesn't seem to have been attempted during staging:


Is there something extra that needs to be installed on s390x.ci.qemu.org to 
have this test run?

No idea. Peter owns the machine. This is one thing to do.
The 2nd thing to do is to fix the regression. Does anyone have an idea what is 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]