[libvirt] [PATCH 00/13] Move functions from qemu_domain_address.c to domain_addr.c

[Laine Stump]

On 07/19/2016 08:07 PM, Tomasz Flendrich wrote:
> This series depends on another one:
> https://www.redhat.com/archives/libvir-list/2016-July/msg00696.html
>
> Because the address sets are no longer cached, it's possible to move
> functions that don't depend on qemu anymore from qemu_domain_address.c
> to domain_addr.c. I did that with virtioSerial and PCI.
>
> To make some functions not dependent on qemuCaps, their parameters
> were changed to booleans. These changes are in [PATCH 02/13].
>
> If you are satisfied with this approach, I can do the same with
> the rest of the functions or just some of them.

The problem is that many/most these functions are by definition 
qemu-specific - only the qemu driver has any concept of a Q35 
machinetype or a PIIX3 controller (actually that function should 
probably have used "i440fx" instead of PIIX3) or an aarch64 "virt" 
machinetype, or any use for a "busNr" etc etc. So moving them from qemu 
into conf is busy-work that is counter-productive.

I guess you're wanting to move these into conf because they are related 
to and used by functions that are assigning/allocating PCI addresses, 
and you want that to be done in a driver-agnostic place. I don't think 
simply moving all these driver-specific functions into driver-agnostic 
files and declaring them driver-agnostic  is the right approach though. 
The "pre-loading/validation" of addresses in these functions based on 
hardware and qemu capabilities should either be called from 
qemu-specific code prior to calling a driver-agnostic address 
allocation/assignment function, or the driver-agnostic function should 
do a callback back into qemu to pre-load/validate the addresses. Beyond 
that, each PCI controller needs flags to indicate what type of slots 
(and how many) it provides, which is driver-specific and so needs to be 
provided by a callback into a driver-specific function, and as each 
device is assigned we need to determine what type of slot it can plug 
into, which will also be driver-specific and thus require a callback 
into a driver-specific function.

This (functions to provide the slot-type-compatibility flags for 
controllers and devices) was something I was about to work on before I 
left for a two week vacation that turned into 3 due to "social unrest" 
(and I've now spent nearly a week just catching up on email). I have a 
lot of accumulated bits of knowledge about this in my brain that I need 
to dump into code, the sooner the better.

>
> Tomasz Flendrich (13):
>    Move and rename qemuDomainAssignVirtioSerialAddresses
>    make pci address handling functions qemu-agnostic
>    Move and rename qemuDomainCollectPCIAddress
>    Move and rename qemuDomainMachineIsQ35 et al
>    Move and rename qemuDomainValidateDevicePCISlotsPIIX3
>    Move and rename qemuDomainValidateDevicePCISlotsQ35
>    Move and rename qemuDomainValidateDevicePCISlotsChipsets
>    Move and rename qemuDomainAddressFindNewBusNr et al
>    Move and rename qemuDomainMachineIsVirt
>    Move and rename qemuDomainSupportsPCI
>    Move and rename qemuDomainPCIAddrSetCreateFromDomain
>    Move and rename qemuDomainAssignPCIAddresses et al
>    Make functions in qemu_domain_address static
>
>   src/conf/domain_addr.c         | 1315 ++++++++++++++++++++++++++++++++++++++++
>   src/conf/domain_addr.h         |   28 +
>   src/libvirt_private.syms       |    6 +
>   src/qemu/qemu_alias.c          |    2 +-
>   src/qemu/qemu_capabilities.c   |    6 +-
>   src/qemu/qemu_command.c        |   20 +-
>   src/qemu/qemu_domain.c         |   55 +-
>   src/qemu/qemu_domain.h         |    3 -
>   src/qemu/qemu_domain_address.c | 1284 +--------------------------------------
>   src/qemu/qemu_domain_address.h |    4 -
>   src/qemu/qemu_hotplug.c        |   33 +-
>   11 files changed, 1406 insertions(+), 1350 deletions(-)
>