[libvirt] [PATCH v6 00/13] PCI passthrough support on s390

[Christian Borntraeger]

On 10/15/2018 09:30 AM, Boris Fiuczynski wrote:
> On 10/14/18 2:47 PM, Andrea Bolognani wrote:
>> On Fri, 2018-10-12 at 16:04 +0100, Daniel P. Berrangé wrote:
>>> On Fri, Sep 28, 2018 at 04:46:13PM +0800, Yi Min Zhao wrote:
>> [...]
>>>>    <hostdev mode='subsystem' type='pci'>
>>>>      <driver name='vfio'/>
>>>>      <source>
>>>>        <address domain='0x0001' bus='0x00' slot='0x00' function='0x0'/>
>>>>      </source>
>>>>      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'>
>>>>        <zpci uid='0x0003' fid='0x00000027'/>
>>>>      </address>
>>>>    </hostdev>
>>>
>>> I'm not sure if this was discussed in earlier versions, but to me
>>> this use of a child element looks wrong.
>>>
>>> What we're effectively saying is that s390 has a different addressing
>>> scheme. It happens to share some fields with the current PCI addressing
>>> scheme, but it is none the less a distinct scheme.
>>>
>>> IOW, I think it should be
>>>
>>>     <address type='zpci' domain='0x0000' bus='0x00' slot='0x01'
>>>                          function='0x0' uid='0x0003' fid='0x00000027'/>
>>>
>>> Of course internally we can still share much logic for assigning the
>>> addreses between "pci" and "zpci".
>>
>> So what happens with PCI devices on s390 is that *two* devices will
>> be added to the guest: one is the usual virtio-net-pci or what have
>> you, which has its own PCI address allocated using the same algorithm
>> as other architectures; the other one is a '-device zpci', which IIUC
>> works basically like an adapter between the PCI device itself and the
>> guest OS, and which is identified using uid and fid.
>>
>> Calling it a completely different address type seems like a bit of a
>> stretch: there is definitely a PCI address involved, which is why the
>> zPCI part was implemented through a potentially reusable "PCI address
>> extension" mechanism.
>>
> I thought that we discussed this in v1 or v2 already when uid anf fid were still embedded in the address element itself. In v5 Andrea suggested to model the two zpci extension parameters outside as a child element of address which corresponds kind of to what is happening in qemu (see Andreas paragraph above).
> The original idea was for users on s390 to make pci no different than on other platforms. Creating a zpci address type would introduce the opposite.
> Currently uid and fid are optional attributes for the user on s390. He can simply enter any kind of pci address as for other platforms. If he does so on s390 the uid and fid would be automatically generated for him. Only if he chooses to specifically set these attributes himself he has to specify uid and/or fid.
Agreed.
In QEMU this is really modelled as PCI (with the classic bus addresses).
The fact that the guest uses the fid/uid instead does not make the PCI bus
addresses in QEMU go away and it should not change the modelling of
the devices.
So I think that the current proposal from Andrea implemented
by Yi Min and endorsed by Boris:
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'>
       <zpci uid='0x0003' fid='0x00000027'/>

is really the best solution.