On Thu, 2018-07-26 at 13:43 +0800, Yi Min Zhao wrote: > 在 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.
I see how that would be pretty limiting. >From the test cases I see a zpci devices, with its own uid and fid, is created for the pci-bridge as well... Is that intentional? > > > > > > 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. Okay, if that's the case we'll definitely have to store the PCI address in the guest XML :( -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
