On Fri, 2018-10-12 at 16:04 +0100, Daniel P. Berrangé wrote: > On Fri, Sep 28, 2018 at 04:46:13PM +0800, Yi Min Zhao wrote: [...] > > <hostdev mode='subsystem' type='pci'> > > <driver name='vfio'/> > > <source> > > <address domain='0x0001' bus='0x00' slot='0x00' function='0x0'/> > > </source> > > <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'> > > <zpci uid='0x0003' fid='0x00000027'/> > > </address> > > </hostdev> > > I'm not sure if this was discussed in earlier versions, but to me > this use of a child element looks wrong. > > What we're effectively saying is that s390 has a different addressing > scheme. It happens to share some fields with the current PCI addressing > scheme, but it is none the less a distinct scheme. > > IOW, I think it should be > > <address type='zpci' domain='0x0000' bus='0x00' slot='0x01' > function='0x0' uid='0x0003' fid='0x00000027'/> > > Of course internally we can still share much logic for assigning the > addreses between "pci" and "zpci". So what happens with PCI devices on s390 is that *two* devices will be added to the guest: one is the usual virtio-net-pci or what have you, which has its own PCI address allocated using the same algorithm as other architectures; the other one is a '-device zpci', which IIUC works basically like an adapter between the PCI device itself and the guest OS, and which is identified using uid and fid. Calling it a completely different address type seems like a bit of a stretch: there is definitely a PCI address involved, which is why the zPCI part was implemented through a potentially reusable "PCI address extension" mechanism. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
