Re: [PATCH v2 1/6] hw/xen: Set XenBackendInstance in the XenDevice before realizing it

[Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>]

Hi David,

"Woodhouse, David" <dwmw@amazon.co.uk> writes:

> On Wed, 2023-11-22 at 17:05 +0000, Paul Durrant wrote:
>> On 21/11/2023 22:10, Volodymyr Babchuk wrote:
>> > From: David Woodhouse <dwmw@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 <dwmw@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.
>
> I think I did that in
> https://git.infradead.org/users/dwmw2/qemu.git/commitdiff/94f1b474478ce0ede
> but didn't get round to sending it out again because of travel.

I can just pull it from this link, if you don't mind.

-- 
WBR, Volodymyr