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(-)
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list