Re: [libvirt] [PATCH v2 RESEND 00/12] PCI passthrough support on s390

在 2018/7/25 下午11:44, Andrea Bolognani 写道: > > > > > How does the pci-bridge controller show up in the guest, if at all? > > > > Qemu hides pci-bridge devices and just exposes pci devices to the guest. > > In above example, indeed, qemu will generate a pci-bridge device and it will > > be existing in pci topology. But the guest can't see it. This is very > > special. > > Yeah, that's kinda problematic as it violates the principle of least > surprise... If s390 guests can only see a flat PCI topology, then we > should find a way to reject bridges altogether instead of allowing > the user to create them (or even create them automatically) only for > them not to show up in the guest. If we reject bridges, there would be only one pci bus that maximum 32 pci devices could be plugged to. This kind of limitation is more problematic IMO.

From the test cases I see a zpci devices, with its own uid and fid,

> > > > > Do the bus= and addr= attributes of vfio-pci and pci-bridge in the > > > > > example above matter eg. for migration purposes? > > > > Do you mean we leave attribute generation for bus and addr to qemu? > > That would be the idea, but of course it can only work if the > address of the underlying PCI device can change without affecting > the guest in any way, including migration. If that's not the case, > and the PCI address needs to be as stable as the IDs, then I don't > think there's a way to avoid storing it in the guest XML, no matter > how confusing that will end up looking. I think it relies on pci base code. Although we don't expose pci address to the guest, any pci device still exists PCI tree tolopogy in qemu. IIUC, this has effect on qemu process itself. For example, if we hotplug a pci device permanently, it will be dynamically assigned with a pci address, and this address might change after shutdown and start again the guest and also might change in destination during migration.