[Top][All Lists]

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

Re: [qemu-s390x] [PATCH v4 04/14] pc: prepare for multi stage hotplug ha

From: David Hildenbrand
Subject: Re: [qemu-s390x] [PATCH v4 04/14] pc: prepare for multi stage hotplug handlers
Date: Wed, 13 Jun 2018 21:37:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

>>>       [ ... specific to machine_foo wiring ...]
>>>       virtio_mem_plug() {
>>>          [... some machine specific wiring ...]
>>>          bus_hotplug_ctrl = qdev_get_bus_hotplug_handler()
>>>          bus_hotplug_ctrl->plug(bus_hotplug_ctrl, dev)
>>>          [... some more machine specific wiring ...]
>>>       }
>>>       [ ... specific to machine_foo wiring ...]
>>> i.e. device itself doesn't participate in attaching to external entities,
>>> those entities (machine or bus controller virtio device is attached to)
>>> do wiring on their own within their own domain.
>> I am fine with this, but Michael asked if this ("virtio_mem_plug()")
>> could go via new DeviceClass functions. Michael, would that also work
>> for your use case?
> It's not virtio specifically, I'm interested in how this will work for
> PCI generally.  Right now we call do_pci_register_device which
> immediately makes it guest visible.

So you're telling me that a PCI device exposes itself to the system in
pci_qdev_realize() instead of letting a hotplug handler handle that? My
assumption is that the PCI bridge hotplug handler handles this. What am
I missing?

I can see that e.g. for a virtio device the realize call chain is

pci_qdev_realize() -> virtio_pci_realize() -> virtio_XXX__pci_realize ->

If any realization in pci_qdev_realize() fails, we do a

So if it is true what you're saying than we're already exposing
partially realized (and possibly unrealized again) devices via PCI. I
*guess* because we're holding the iothread mutex this is okay and
actually not visible. And we only seem to be sending events in the PCI
bridge hotplug handlers, so my assumption is that this is fine.

>> -- 
>> Thanks,
>> David / dhildenb



David / dhildenb

reply via email to

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