regression on s390: was Re: [PULL 37/40] monitor: Tidy up find_device_state()

From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Richard Henderson <richard.henderson@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>,
	qemu block <qemu-block@nongnu.org>
Cc: "Damien Hedde" <damien.hedde@greensocs.com>,
	"Kevin Wolf" <kwolf@redhat.com>,
	qemu-s390x <qemu-s390x@nongnu.org>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Hanna Reitz" <hreitz@redhat.com>
Subject: regression on s390: was Re: [PULL 37/40] monitor: Tidy up find_device_state()
Date: Mon, 18 Oct 2021 12:08:56 +0200	[thread overview]
Message-ID: <056a0299-f6f8-9e59-8d2e-db7413210f75@de.ibm.com> (raw)
In-Reply-To: <c01b47a1-43e2-71b7-1cdd-9a1d0f685eb3@linaro.org>

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:
> 
>    https://gitlab.com/qemu-project/qemu/-/jobs/1681194907
> 
> 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 broken?