On 07/24/2018 03:41 PM, Andrea Bolognani wrote:
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.
From a user perspective:
I take your example below and reduce it to pci only like this:
<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'/>
</hostdev>
This works on x86 as well as on s390 where as your suggested zpci
address type would not allow this. This is what I wanted to express with
the word "compatible".
As I wrote before: It would also be valid for a user to not care about
the attributes domain, bus, slot and function and reduce the specified
set of attributes to e.g. <address type='pci' uid='0xffff'/>
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.
Sure you can add one more but wouldn't you end up with e.g. a hostdev
model vfio-pci with an address type of pci on all pci supporting
architectures but s390 where you need to use zpci? What would be the
benefit for the user or higher level management software? Actually I
would not like to introduce special handling unless required.
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.
--
Mit freundlichen Grüßen/Kind regards
Boris Fiuczynski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
