On Tue, 24 Jul 2018 10:20:48 +0200 Andrea Bolognani <abologna@redhat.com> wrote:
Looking at both the generated QEMU command line and the qemu-devel message linked above, I seem to understand the zpci device is basically some sort of adapter that sits between a regular PCI device (emulated or otherwise) and an s390 guest and presents an ID-based interface to the latter; so IIUC the s390 guest doesn't actually see a PCI device, but a couple of IDs that can (somehow) be used to access the underlying PCI device.
From whatever little s390 knowledge I have, I recall the architecture using peculiar ways to address and access devices, so PCI not being usable wouldn't surprise me that much; what I find odd, however, is that regular PCI seems to be available at least on the host side, because otherwise stuff like
-device zpci,uid=1,fid=1,target=vpci0 -device vfio-pci,host=0000:00:00.0,id=vpci0
wouldn't be possible. So, would anyone with s390 knowledge please spend a few words explaining how the various pieces fit together?
For some hints, let me point to https://virtualpenguins.blogspot.de/2018/02/notes-on-pci-on-s390x.html -- for implementation details, I'll point to the IBM folks :)
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'/>
be a better representation of the arrangement? We could leave it up to QEMU to assign addresses to the PCI devices in this case... But maybe they still matter for things such as migration? Or maybe I've just gotten it wrong altogether? :)