[libvirt] [PATCH v5 03/15] qemu: set/use info->pciConnectFlags when validating/assigning PCI addresses

Andrea Bolognani abologna at redhat.com
Wed Oct 26 07:55:13 UTC 2016


On Tue, 2016-10-25 at 14:08 -0400, Laine Stump wrote:
> > [...]
> > > @@ -926,7 +857,7 @@ qemuDomainCollectPCIAddress(virDomainDefPtr def ATTRIBUTE_UNUSED,
> > >        entireSlot = (addr->function == 0 &&
> > >                      addr->multi != VIR_TRISTATE_SWITCH_ON);
> > >    
> > > -    if (virDomainPCIAddressReserveAddr(addrs, addr, flags,
> > > +    if (virDomainPCIAddressReserveAddr(addrs, addr, info->pciConnectFlags,
> > >                                           entireSlot, true) < 0)
> > Would it be cleaner to have a qemuDomainPCIAddressReserveAddr()
> > function that takes @info directly?
> 
> Actually in a later series (the one that cleans up the *Slot() vs 
> *Addr() naming), I eliminated all but one of the 
> qemuDomainPCIAddressReserve*() functions anyway. After that series, 
> there are only two *PCIAddressReserve*() functions used in this file: 
> qemuDomainPCIAddressReserveNextAddr() (21 times), and 
> virDomainPCIAddressReserveAddr() (12 times). The latter can't have a 
> nice flags-removing wrapper added in qemu_domain_address.c (like the 
> former does) because it often is called with a bare address - no DeviceInfo
> 
> (Well, I don't know, maybe it could be done by reorganizing some of the 
> calls, I'll have to look at it).
> 
> > It would be used only a single time, so it could very well be
> > argued that it would be overkill... On the other hand, it would
> > be neat not to use virDomainPCIAddressReserve*() functions at
> > all in the qemu driver and rely solely on the wrappers instead.
>> > Speaking of which, even with the full series applied there
> > are still a bunch of uses of virDomainPCIAddressReserveAddr()
> > and virDomainPCIAddressReserveSlot(), mostly in
> > qemuDomainValidateDevicePCISlots{PIIX3,Q35}().
> 
> Yeah, my later series turns all of those into 
> virDomainPCIAddressReserveAddr().

Sorry, I haven't looked at any of your follow-up series at
all yet. Disregard my comments then :)

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list