在 2018/7/25 下午11:44, Andrea Bolognani 写道:
On Wed, 2018-07-25 at 16:34 +0800, Yi Min Zhao wrote:
在 2018/7/24 下午11:43, Andrea Bolognani 写道:
More concrete questions: one of the zPCI test cases includes
<controller type='pci' index='1' model='pci-bridge'/>
<hostdev mode='subsystem' type='pci' managed='no'>
<driver name='vfio'/>
<source>
<address domain='0xffff' bus='0x00' slot='0x00' function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x01' slot='0x1f'
function='0x0' uid='0xffff' fid='0xffffffff'/>
</hostdev>
which translates to
-device zpci,uid=3,fid=2,target=pci.1,id=zpci3 \
-device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0x1 \
-device zpci,uid=65535,fid=4294967295,target=hostdev0,id=zpci65535 \
-device vfio-pci,host=ffff:00:00.0,id=hostdev0,bus=pci.1,addr=0x1f \
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.
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.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
