Re: [libvirt] [PATCH v2 RESEND 00/12] PCI passthrough support on s390
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.
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.
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.
--
Andrea Bolognani / Red Hat / Virtualization