Re: [PATCH v2] virtio: Add function name to error messages

[Markus Armbruster <armbru@redhat.com>]

Alessandro Ratti <alessandro@0x65c.net> writes:

> On Mon, 22 Sept 2025 at 16:23, Markus Armbruster <armbru@redhat.com> wrote:
>>
>> Alessandro Ratti <alessandro.ratti@gmail.com> writes:
>>
>> > Hi Markus, Alex, Daniel,
>> >
>> > Thanks again for the thoughtful feedback and for helping me see the bigger
>> > picture. I now fully agree that adding function names to error messages (via
>> > __func__) doesn't really address the core issue, and I appreciate the
>> > push to rethink how error reporting can better serve both users and developers.
>> >
>> > I've taken a first stab at improving one of the messages in
>> > virtio_init_region_cache(), following your suggestions.
>> >
>> > Here's the updated call:

[...]

>> > With this change, the error output now reads:
>> >
>> >     qemu-system-x86_64: Failed to map used ring for device
>> > 0000:00:04.0 - possible guest misconfiguration or insufficient memory
>> >
>> > This feels like a clear improvement — it gives context (what failed),
>> > identifies the device, and hints at likely causes.
>>
>> It's *much* better!
>>
>> Developers will appreciate "Failed to map used ring for device".  By
>> itself it would still be gobbledygook for users, but together with the
>> "possible guest misconfiguration or insufficient memory" clue it's fine.
>>
>> Perhaps we can still improve on "device 0000:00:04.0".  The device's ID
>> is a good way to identify it to the user, because it's chosen by the
>> user, and unique (among devices).  Sadly, devices without ID exist.  We
>> fall back to canonical QOM path in places.  Have a look at
>> qdev_get_human_name() to see whether it works here.
>
> I experimented with qdev_get_human_name(), but it usually returns paths like:
>
>   /machine/peripheral-anon/device[0]/virtio-backend
>
> …which seems less user-friendly than the PCI address provided by
> qdev_get_dev_path().
> For now, I'm sticking to using the device ID when set (e.g. via -device…,id=foo)
> and falling back to qdev_get_dev_path() otherwise — which provides predictable
> output for both PCI and non-PCI devices.

Note that qdev_get_dev_path() may return null.  You need another
fallback.

For what it's worth, "qdev ID or QOM path" is how users specify devices
in QMP.

[...]