On Tue, 24 Jul 2018 10:20:48 +0200
Andrea Bolognani <abologna(a)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? :)