Paul Durrant <xadimg...@gmail.com> writes:
> On 21/11/2023 22:10, Volodymyr Babchuk wrote:
>> From: David Woodhouse <d...@amazon.co.uk>
>> This allows a XenDevice implementation to know whether it was
>> created
>> by QEMU, or merely discovered in XenStore after the toolstack created
>> it. This will allow us to create frontend/backend nodes only when we
>> should, rather than unconditionally attempting to overwrite them from
>> a driver domain which doesn't have privileges to do so.
>> As an added benefit, it also means we no longer have to call the
>> xen_backend_set_device() function from the device models immediately
>> after calling qdev_realize_and_unref(). Even though we could make
>> the argument that it's safe to do so, and the pointer to the unreffed
>> device *will* actually still be valid, it still made my skin itch to
>> look at it.
>> Signed-off-by: David Woodhouse <d...@amazon.co.uk>
>> ---
>> hw/block/xen-block.c | 3 +--
>> hw/char/xen_console.c | 2 +-
>> hw/net/xen_nic.c | 2 +-
>> hw/xen/xen-bus.c | 4 ++++
>> include/hw/xen/xen-backend.h | 2 --
>> include/hw/xen/xen-bus.h | 2 ++
>> 6 files changed, 9 insertions(+), 6 deletions(-)
>>
>
> Actually, I think you should probably update
> xen_backend_try_device_destroy() in this patch too. It currently uses
> xen_backend_list_find() to check whether the specified XenDevice has
> an associated XenBackendInstance.
Sure. Looks like it is the only user of xen_backend_list_find(), so we
can get rid of it as well.
I'll drop your R-b tag, because of those additional changes in the new
version.
--
WBR, Volodymyr
