On 09/12/2017 02:21 AM, Thomas Huth wrote:
> On 11.09.2017 19:19, Eric Blake wrote:
>> When initializing a QVirtioDevice (which always has an associated
>> QVirtioBus), we want to track which QTestState to use for all
>> I/O processed through that bus and device.  Copy the paradigm
>> used for QPCIBus, and track the test state at the bus level; this
>> in turn requires a separate bus object per device (and associated
>> cleanup) rather than just sharing a const version of the dispatch
>> table.
> I fail to see why we need a separate bus object here for each device.
> The bus is only available one time, not multiple times, isn't it? So
> there should also only be one bus object floating around, not multiple
> ones... or do I miss something?

You are right that there is only one bus for the machine - the problem
is that the object representing the bus is dynamically created on the
fly at the point where the device is first grabbed, rather than up front
as part of creating the machine (in other words, the device search is
not performed on a pre-existing bus object).

Contrast qpci_device_find() (lookup based on a pre-existing bus) with
qvirtio_mmio_init_device() (lookup that did not use a pre-existing bus);
also note that qvirtio_pci_device_find() takes a pre-existing QPCIBus
(since on that architecture, the QVirtioBus is itself a device on the
QPCIBus).

I suppose that we could indeed refactor the code to require callers to
create the QVirtioBus object up front, and then make the device lookup
(both qvirtio_mmio_init_device() and qvirtio_pci_device_find()) take a
QVirtioBus parameter instead of QTestState or QPCIBus.  That's slightly
more work, but I'm happy to attempt it if you think it will be better.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org