在 2018/7/30 下午7:08, Andrea Bolognani 写道:
On Fri, 2018-07-27 at 13:22 +0800, Yi Min Zhao wrote:
在 2018/7/24 下午10:58, Andrea Bolognani 写道:
@@ -1385,7 +1403,12 @@ qemuDomainCollectPCIAddress(virDomainDefPtr def 
ATTRIBUTE_UNUSED,
            * parent, and will have its address collected during the scan
            * of the parent's device type.
           */
-        return 0;
+        if (info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI ||
+            info->type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE)
+            return virDomainPCIAddressExtensionReserveAddr(addrs, addr,
+                                                           
info->pciAddressExtFlags);
+        else
+            return 0;
This doesn't look right: the comment specifically states that the
PCI address will be handled by the parent device in this case,
why wouldn't the zPCI address not be handled in the same way?
For this comment, we have to collect zPCI address in case that zPCI
address is specified
but PCI address is not. I think I shall split two checks. Original code is:
if (!virDeviceInfoPCIAddressPresent(info) ||
      ((device->type == VIR_DOMAIN_DEVICE_HOSTDEV) &&
        (device->data.hostdev->parent.type != VIR_DOMAIN_DEVICE_NONE)))
Separate them and only add the new code for
!virDeviceInfoPCIAddressPresent(info) case.
I didn't look too closely, but I think you might have to change
virDeviceInfoPCIAddressPresent() itself so that it knows about PCI
address extensions and behaves accordingly.

Basically, with the introduction of PCI address extensions, you're
making questions such as "does this device have a PCI address
assigned to it?" a lot less trivial to answer, and you need to
ensure this doesn't cause existing assumption to no longer hold.

I have a new idea. qemuDomainCollectPCIAddress() is called in one place. So we could
add a new function qemuDomainCollectPCIExtensionAddress(), and call it after
qemuDomainCollectPCIAddress() is called. Then we could collect pci address and
extension address separately.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to