[libvirt] [PATCH 0/4] Move ccwaddrs and pciaddrs to domainDef

[Cole Robinson]

On 06/20/2016 10:26 PM, Tomasz Flendrich wrote:
> 
>> Apologies if I'm missing something, I didn't look too closely at this series,
>> however have you seen this thread?
>>
>> http://www.redhat.com/archives/libvir-list/2016-May/msg01071.html
> I haven’t noticed that some work has been done on that, thank you!
> 
>> My understanding of the current code is that the cached vioserial/ccw/pciaddrs
>> lists in qemu aren't actually required…they were at one point to handle
> 
>> older qemu, but we dropped that support. Maybe you can pick up my patches and
>> finish off dropping of pciaddrs and ccwaddrs? I suspect the pciaddrs cache in
>> bhyve can be dropped as well, I don't think it was ever strictly required, the
>> code just followed the qemu example
> If we could do without the caching, it would make the current code simpler.
> There wouldn’t be those booleans in qemu_hotplug.c that remember whether
> an address has to be deleted or not in case something fails. We could 
> delete qemuDomainReleaseDeviceAddress() and a few more functions.
> 
> I examined vioserial and pci addresses and it looks like
> it could be done. However, I'm not an expert on qemu_hotplug yet
> and this is where the interesting stuff happens with addresses,
> so I am not entirely sure yet.
> I also don't know what the plans are for device addresses in the future.
> Perhaps there are some features that will require caching them.
> 

In a way they are currently cached twice: once in these lists, and once in the
runtime VM XML. That's what my vioserial series did, was replace the hotplug
usage of the cached list with just fetching it on demand from the running VM
XML, so at least at a high level these cached lists seem redundant because the
info is tracked elsewhere.

> I think that recalculation may change the current behavior of ccw addresses.
> Function virDomainCCWAddressReleaseAddr() modifies addrs->next
> only when the address being released was the address most recently
> assigned.
> 

Hmm, that's interesting. Not sure what that is about. I tried adding this diff:

diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c
index 794270d..7d39b69 100644
--- a/src/conf/domain_addr.c
+++ b/src/conf/domain_addr.c
@@ -792,14 +792,7 @@ virDomainCCWAddressReleaseAddr(virDomainCCWAddressSetPtr
addrs,
     if (!addr)
         return -1;

-    if ((ret = virHashRemoveEntry(addrs->defined, addr)) == 0 &&
-        dev->addr.ccw.cssid == addrs->next.cssid &&
-        dev->addr.ccw.ssid == addrs->next.ssid &&
-        dev->addr.ccw.devno < addrs->next.devno) {
-        addrs->next.devno = dev->addr.ccw.devno;
-        addrs->next.assigned = false;
-    }
-
+    ret = virHashRemoveEntry(addrs->defined, addr);
     VIR_FREE(addr);

     return ret;


And the test suite doesn't break, so at least it's not something completely
obvious. But then again this seems to only be via hotunplug call path, and our
test suite coverage for hotplug isn't that great.

This logic may in fact just be an artifact of maintaining a persistent set of
addresses. If we are generating an address set on demand from the runtime XML,
we probably don't need to worry about 'releasing' an address from that set at
all, so it may just side step whatever issue this logic was trying to address.

> Laine, you know a lot about PCI addresses and you also mentioned that
> you want to modify them in the future. What do you think?
> 

Laine did have some patches that did touch some bits in this area, but only as
a side effect.

Thanks,
Cole