On 07/24/2018 03:41 PM, Andrea Bolognani wrote:
On Tue, 2018-07-24 at 11:31 +0200, Boris Fiuczynski wrote:
On 07/24/2018 10:20 AM, Andrea Bolognani wrote:
Assuming the above is a correct reading of the situation, it would seem the IDs are the only guest-visible part that we need to make sure doesn't change during the lifetime of the guest, while the usual bus/slot/function triplet assigned to the underlying PCI device doesn't actually matter. And if that's the case, wouldn't something like
<address type='zpci' uid='1' fid='1'/>
Then a pci device on s390 would need a special address type zpci in libvirt and the design idea for libvirt is to stay compatible with pci.
Being compatible with the existing PCI machinery is certainly a good idea when it makes sense to do so, but I'm not quite convinced that is the case here.
From a user perspective: I take your example below and reduce it to pci only like this: <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'/> </hostdev> This works on x86 as well as on s390 where as your suggested zpci address type would not allow this. This is what I wanted to express with the word "compatible". As I wrote before: It would also be valid for a user to not care about the attributes domain, bus, slot and function and reduce the specified set of attributes to e.g. <address type='pci' uid='0xffff'/>
According to Cornelia's blog post on the subject, the PCI topology inside the guest will be determined entirely by the IDs. Is there even a way to eg. use bridges to create a non-flat PCI hierarchy? Or to have several PCI devices share the same bus or slot?
If none of the above applies, then that doesn't look a whole lot like PCI to me :)
Moreover, we already have several address types in addition to PCI such as USB, virtio-mmio, spapr-vio, ccw... Adding yet another one is not a problem if it makes the interface more sensible.
Sure you can add one more but wouldn't you end up with e.g. a hostdev model vfio-pci with an address type of pci on all pci supporting architectures but s390 where you need to use zpci? What would be the benefit for the user or higher level management software? Actually I would not like to introduce special handling unless required.
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?
Do the bus= and addr= attributes of vfio-pci and pci-bridge in the example above matter eg. for migration purposes?
Therefore uid and fid are optional attributes and if not specified on s390 they are generated. The patch series also allows on s390 to specify the pci address type just with attributes uid and/or fid causing the rest of the pci address attributes to be generated.
This goes without saying: users should not have to worry about addresses at all unless they have very specific needs.
-- Mit freundlichen Grüßen/Kind regards Boris Fiuczynski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294