[libvirt] [PATCH] qemu: avoid double reservation of PCI address when hotplugging interface type='hostdev'

[Andrea Bolognani]

On Tue, 2019-10-22 at 14:25 -0400, Laine Stump wrote:
> On 10/21/19 9:02 AM, Andrea Bolognani wrote:
> > On Sat, 2019-10-19 at 02:18 -0400, Laine Stump wrote:
> > > Commit 01ca4010d86 (libvirt v5.1.0) moved address reservation for
> > > hotplugged interface devices up to an earlier point in
> > > qemuDomainAttachNetDevice() because some function called when
> > > hotplugging on aarch64 needed to know the address type, and failed
> > > when it was "none".
> > 
> > I don't see anything in the original commit suggesting the change
> > was connected to aarch64? In fact, for the most part I would expect
> > aarch64/virt guests to go down the very same code paths as x86/q35
> > guests.
> 
> The secret info is in the emails surrounding the V1 patch that turned 
> into the V2 patch that was eventually pushed:
> 
> https://www.redhat.com/archives/libvir-list/2018-December/msg00439.html
> https://www.redhat.com/archives/libvir-list/2018-December/msg00460.html
> 
> I think the issue is that in the VIR_DOMAIN_NET_TYPE_VHOSTUSER case of 
> the switch statement in qemuDomainAttachNetDevice(), it is calling 
> qemuDomainSupportsNicdev(), and qemuDomainSupportsNicdev has this code:
> 
> /* non-virtio ARM nics require legacy -net nic */
> if (((def->os.arch == VIR_ARCH_ARMV6L) ||
>      (def->os.arch == VIR_ARCH_ARMV7L) ||
>      (def->os.arch == VIR_ARCH_AARCH64)) &&
>      net->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO &&
>      net->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI)
>          return false;
> return true;
> 
> So if you were attempting to hotplug a vhostuser device on aarch64 with 
> no address specified in the XML, it would return false, which would 
> cause qemuDomainAttachNetDevice() to fail and log an error.

Alright, it makes more sense now.

Maybe you could mention qemuDomainSupportsNicdev() specifically
instead of vaguely talking about "some function"? That would make
the explanation a bit more self-contained and possibly make it
unnecessary for the next developer to dig through the mailing list
archives. Up to you.

-- 
Andrea Bolognani / Red Hat / Virtualization