Series comparison

When traversing the list of pci devices assigned to a domain cope with
some of them not having the vpci struct allocated. It's possible for
the hardware domain to have read-only devices assigned that are not
handled by vPCI, or for unprivileged domains to have some devices
handled by an emulator different than vPCI.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/drivers/vpci/header.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index XXXXXXX..XXXXXXX 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -XXX,XX +XXX,XX @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)
      */
     for_each_pdev ( pdev->domain, tmp )
     {
+        if ( !tmp->vpci )
+            /*
+             * For the hardware domain it's possible to have devices assigned
+             * to it that are not handled by vPCI, either because those are
+             * read-only devices, or because vPCI setup has failed.
+             *
+             * For unprivileged domains we should aim for passthrough devices
+             * to be capable of being handled by different emulators, and hence
+             * a domain could have some devices handled by vPCI and others by
+             * QEMU for example, and the later won't have pdev->vpci
+             * allocated.
+             */
+            continue;
+
         if ( tmp == pdev )
         {
             /*
-- 
2.40.0

When traversing the list of pci devices assigned to a domain cope with
some of them not having the vpci struct allocated. It should be
possible for the hardware domain to have read-only devices assigned
that are not handled by vPCI, such support will be added by further
patches.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v1:
 - Do not mention domU plans.
---
 xen/drivers/vpci/header.c | 8 ++++++++
 1 file changed, 8 insertions(+)