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.
 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to