[libvirt] [PATCH v2 RESEND 00/12] PCI passthrough support on s390

[Cornelia Huck]

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