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

Yi Min Zhao posted 13 patches 5 years, 6 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/libvirt tags/patchew/20180928084626.76279-1-zyimin@linux.ibm.com
There is a newer version of this series
cfg.mk                                        |   1 +
docs/formatdomain.html.in                     |   9 +-
docs/news.xml                                 |  11 +
docs/schemas/basictypes.rng                   |  27 ++
docs/schemas/domaincommon.rng                 |   1 +
src/conf/device_conf.c                        |  90 +++++
src/conf/device_conf.h                        |   7 +
src/conf/domain_addr.c                        | 332 ++++++++++++++++++
src/conf/domain_addr.h                        |  30 ++
src/conf/domain_conf.c                        |  14 +-
src/libvirt_private.syms                      |   7 +
src/qemu/qemu_capabilities.c                  |   6 +
src/qemu/qemu_capabilities.h                  |   1 +
src/qemu/qemu_command.c                       | 102 ++++++
src/qemu/qemu_command.h                       |   2 +
src/qemu/qemu_domain.c                        |  39 ++
src/qemu/qemu_domain_address.c                | 204 ++++++++++-
src/qemu/qemu_hotplug.c                       | 162 ++++++++-
src/util/virpci.c                             |   7 +
src/util/virpci.h                             |  14 +
.../caps_2.10.0.s390x.xml                     |   1 +
.../caps_2.11.0.s390x.xml                     |   1 +
.../caps_2.12.0.s390x.xml                     |   1 +
.../qemucapabilitiesdata/caps_2.7.0.s390x.xml |   1 +
.../qemucapabilitiesdata/caps_2.8.0.s390x.xml |   1 +
.../qemucapabilitiesdata/caps_2.9.0.s390x.xml |   1 +
.../qemucapabilitiesdata/caps_3.0.0.s390x.xml |   1 +
.../disk-virtio-s390-zpci.args                |  26 ++
.../disk-virtio-s390-zpci.xml                 |  19 +
.../hostdev-vfio-zpci-autogenerate.args       |  25 ++
.../hostdev-vfio-zpci-autogenerate.xml        |  18 +
.../hostdev-vfio-zpci-boundaries.args         |  29 ++
.../hostdev-vfio-zpci-boundaries.xml          |  30 ++
.../hostdev-vfio-zpci-multidomain-many.args   |  39 ++
.../hostdev-vfio-zpci-multidomain-many.xml    |  79 +++++
tests/qemuxml2argvdata/hostdev-vfio-zpci.args |  25 ++
tests/qemuxml2argvdata/hostdev-vfio-zpci.xml  |  21 ++
tests/qemuxml2argvtest.c                      |  20 ++
.../disk-virtio-s390-zpci.xml                 |  31 ++
.../hostdev-vfio-zpci-autogenerate.xml        |  34 ++
.../hostdev-vfio-zpci-boundaries.xml          |  48 +++
.../hostdev-vfio-zpci-multidomain-many.xml    |  97 +++++
.../qemuxml2xmloutdata/hostdev-vfio-zpci.xml  |  32 ++
tests/qemuxml2xmltest.c                       |  17 +
44 files changed, 1648 insertions(+), 15 deletions(-)
create mode 100644 tests/qemuxml2argvdata/disk-virtio-s390-zpci.args
create mode 100644 tests/qemuxml2argvdata/disk-virtio-s390-zpci.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci.xml
create mode 100644 tests/qemuxml2xmloutdata/disk-virtio-s390-zpci.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-boundaries.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-multidomain-many.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci.xml
[libvirt] [PATCH v6 00/13] PCI passthrough support on s390
Posted by Yi Min Zhao 5 years, 6 months ago
Abstract
========
The PCI representation in QEMU has recently been extended for S390
allowing configuration of zPCI attributes like uid (user-defined
identifier) and fid (PCI function identifier).
The details can be found here:
https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07262.html

To support the new zPCI feature of the S390 platform, a new element of
PCI address is introduced. It has two optional attributes, @uid and
@fid. For example:
  <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>

If they are defined by the user, unique values within the guest domain
must be used. If they are not specified and the architecture requires
them, they are automatically generated with non-conflicting values.

zPCI address as an extension of the PCI address are stored in a new
structure 'virZPCIDeviceAddress' which is a member of common PCI
Address structure. Additionally, two hashtables are used for assignment
and reservation of zPCI uid/fid.

In support of extending the PCI address, a new PCI address extension flag is
introduced. This extension flag allows is not only dedicated for the S390
platform but also other architectures needing certain extensions to PCI
address space.

Code Base
=========
commit in master:
b1a0f691ce4652fc71aca6776f085355040322da
spec: Build ceph and gluster support everywhere

Change Log
==========
v5->v6:
1. Modify zPCI XML definition.
2. Optimize the logic of zPCI address assignment and reservation.
3. Add extension flag into PCI address structure.
4. Update commit messages.

v4->v5:
1. Update the version number.
2. Fixup code style error.
3. Separate qemu code into single patch.
4. Rebase the patches to the new code of master branch.

v3->v4:
1. Update docs.
2. Format code style.
3. Optimize zPCI support check.
4. Move the check of zPCI defined in xml but unsupported by Qemu to
   qemuDomainDeviceDefValidate().
5. Change zpci address member of PCI address struct from pointer to
   instance.
6. Modify zpci address definition principle. Currently the user must
   either define both of uid and fid or not.

v2->v3:
1. Revise code style.
2. Update test cases.
3. Introduce qemuDomainCollectPCIAddressExtension() to collect PCI
   extension addresses.
4. Introduce virDeviceInfoPCIAddressExtensionPresent() to check if zPCI
   address exists.
5. Optimize zPCI address check logic.
6. Optimize passed parameters of zPCI addr alloc/release/reserve functions.
7. Report enum range error in qemuDomainDeviceSupportZPCI().
8. Update commit messages.

v1->v2:
1. Separate test commit and merge testcases into corresponding commits that
   introduce the functionalities firstly.
2. Spare some checks for zpci device.
3. Add vsock and controller support.
4. Add uin32 type schema.
5. Rename zpciuid and zpcifid to zpci_uid and zpci_fid.
6. Always return multibus support on S390.

Yi Min Zhao (13):
  conf: Add definitions for 'uid' and 'fid' PCI address attributes
  qemu: Introduce zPCI capability
  conf: Introduce a new PCI address extension flag
  qemu: Enable PCI multi bus for S390 guests
  qemu: Auto add pci-root for s390/s390x guests
  conf: Introduce address caching for PCI extensions
  conf: Introduce parser, formatter for uid and fid
  qemu: Add zPCI address definition check
  conf: Allocate/release 'uid' and 'fid' in PCI address
  qemu: Generate and use zPCI device in QEMU command line
  qemu: Add hotpluging support for PCI devices on S390 guests
  docs: Add 'uid' and 'fid' information
  news: Update news for PCI address extension attributes

 cfg.mk                                        |   1 +
 docs/formatdomain.html.in                     |   9 +-
 docs/news.xml                                 |  11 +
 docs/schemas/basictypes.rng                   |  27 ++
 docs/schemas/domaincommon.rng                 |   1 +
 src/conf/device_conf.c                        |  90 +++++
 src/conf/device_conf.h                        |   7 +
 src/conf/domain_addr.c                        | 332 ++++++++++++++++++
 src/conf/domain_addr.h                        |  30 ++
 src/conf/domain_conf.c                        |  14 +-
 src/libvirt_private.syms                      |   7 +
 src/qemu/qemu_capabilities.c                  |   6 +
 src/qemu/qemu_capabilities.h                  |   1 +
 src/qemu/qemu_command.c                       | 102 ++++++
 src/qemu/qemu_command.h                       |   2 +
 src/qemu/qemu_domain.c                        |  39 ++
 src/qemu/qemu_domain_address.c                | 204 ++++++++++-
 src/qemu/qemu_hotplug.c                       | 162 ++++++++-
 src/util/virpci.c                             |   7 +
 src/util/virpci.h                             |  14 +
 .../caps_2.10.0.s390x.xml                     |   1 +
 .../caps_2.11.0.s390x.xml                     |   1 +
 .../caps_2.12.0.s390x.xml                     |   1 +
 .../qemucapabilitiesdata/caps_2.7.0.s390x.xml |   1 +
 .../qemucapabilitiesdata/caps_2.8.0.s390x.xml |   1 +
 .../qemucapabilitiesdata/caps_2.9.0.s390x.xml |   1 +
 .../qemucapabilitiesdata/caps_3.0.0.s390x.xml |   1 +
 .../disk-virtio-s390-zpci.args                |  26 ++
 .../disk-virtio-s390-zpci.xml                 |  19 +
 .../hostdev-vfio-zpci-autogenerate.args       |  25 ++
 .../hostdev-vfio-zpci-autogenerate.xml        |  18 +
 .../hostdev-vfio-zpci-boundaries.args         |  29 ++
 .../hostdev-vfio-zpci-boundaries.xml          |  30 ++
 .../hostdev-vfio-zpci-multidomain-many.args   |  39 ++
 .../hostdev-vfio-zpci-multidomain-many.xml    |  79 +++++
 tests/qemuxml2argvdata/hostdev-vfio-zpci.args |  25 ++
 tests/qemuxml2argvdata/hostdev-vfio-zpci.xml  |  21 ++
 tests/qemuxml2argvtest.c                      |  20 ++
 .../disk-virtio-s390-zpci.xml                 |  31 ++
 .../hostdev-vfio-zpci-autogenerate.xml        |  34 ++
 .../hostdev-vfio-zpci-boundaries.xml          |  48 +++
 .../hostdev-vfio-zpci-multidomain-many.xml    |  97 +++++
 .../qemuxml2xmloutdata/hostdev-vfio-zpci.xml  |  32 ++
 tests/qemuxml2xmltest.c                       |  17 +
 44 files changed, 1648 insertions(+), 15 deletions(-)
 create mode 100644 tests/qemuxml2argvdata/disk-virtio-s390-zpci.args
 create mode 100644 tests/qemuxml2argvdata/disk-virtio-s390-zpci.xml
 create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.args
 create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.xml
 create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.args
 create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.xml
 create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.args
 create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.xml
 create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci.args
 create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci.xml
 create mode 100644 tests/qemuxml2xmloutdata/disk-virtio-s390-zpci.xml
 create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate.xml
 create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-boundaries.xml
 create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-multidomain-many.xml
 create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci.xml

-- 
Yi Min

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v6 00/13] PCI passthrough support on s390
Posted by Daniel P. Berrangé 5 years, 5 months ago
On Fri, Sep 28, 2018 at 04:46:13PM +0800, Yi Min Zhao wrote:
> Abstract
> ========
> The PCI representation in QEMU has recently been extended for S390
> allowing configuration of zPCI attributes like uid (user-defined
> identifier) and fid (PCI function identifier).
> The details can be found here:
> https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07262.html
> 
> To support the new zPCI feature of the S390 platform, a new element of
> PCI address is introduced. It has two optional attributes, @uid and
> @fid. For example:
>   <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".

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v6 00/13] PCI passthrough support on s390
Posted by Andrea Bolognani 5 years, 5 months ago
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.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v6 00/13] PCI passthrough support on s390
Posted by Yi Min Zhao 5 years, 5 months ago

在 2018/10/14 下午8:47, Andrea Bolognani 写道:
> 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.
>
Sorry, this mail went into trash box..

-- 
Yi Min

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v6 00/13] PCI passthrough support on s390
Posted by Boris Fiuczynski 5 years, 5 months ago
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.

-- 
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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v6 00/13] PCI passthrough support on s390
Posted by Christian Borntraeger 5 years, 5 months ago

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
Re: [libvirt] [PATCH v6 00/13] PCI passthrough support on s390
Posted by Yi Min Zhao 5 years, 5 months ago

在 2018/10/12 下午11:04, Daniel P. Berrangé 写道:
> On Fri, Sep 28, 2018 at 04:46:13PM +0800, Yi Min Zhao wrote:
>> Abstract
>> ========
>> The PCI representation in QEMU has recently been extended for S390
>> allowing configuration of zPCI attributes like uid (user-defined
>> identifier) and fid (PCI function identifier).
>> The details can be found here:
>> https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07262.html
>>
>> To support the new zPCI feature of the S390 platform, a new element of
>> PCI address is introduced. It has two optional attributes, @uid and
>> @fid. For example:
>>    <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".
>
> Regards,
> Daniel
Hi Daniel,

Thanks for your comment! We have discussed on this in previous review 
rounds.
Treating zpci as an element is our latest agreement. If do it as your 
suggestion,
we have to re-start reviewing the code. But I hope we could do it in the 
most
appropriate way eventually. How about Andrea's idea? @Andrea

Regards,

Yi Min

-- 
Yi Min

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v6 00/13] PCI passthrough support on s390
Posted by Boris Fiuczynski 5 years, 5 months ago
Polite ping...

On 9/28/18 10:46 AM, Yi Min Zhao wrote:
> Abstract
> ========
> The PCI representation in QEMU has recently been extended for S390
> allowing configuration of zPCI attributes like uid (user-defined
> identifier) and fid (PCI function identifier).
> The details can be found here:
> https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07262.html
> 
> To support the new zPCI feature of the S390 platform, a new element of
> PCI address is introduced. It has two optional attributes, @uid and
> @fid. For example:
>    <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>
> 
> If they are defined by the user, unique values within the guest domain
> must be used. If they are not specified and the architecture requires
> them, they are automatically generated with non-conflicting values.
> 
> zPCI address as an extension of the PCI address are stored in a new
> structure 'virZPCIDeviceAddress' which is a member of common PCI
> Address structure. Additionally, two hashtables are used for assignment
> and reservation of zPCI uid/fid.
> 
> In support of extending the PCI address, a new PCI address extension flag is
> introduced. This extension flag allows is not only dedicated for the S390
> platform but also other architectures needing certain extensions to PCI
> address space.
> 
> Code Base
> =========
> commit in master:
> b1a0f691ce4652fc71aca6776f085355040322da
> spec: Build ceph and gluster support everywhere
> 
> Change Log
> ==========
> v5->v6:
> 1. Modify zPCI XML definition.
> 2. Optimize the logic of zPCI address assignment and reservation.
> 3. Add extension flag into PCI address structure.
> 4. Update commit messages.
> 
> v4->v5:
> 1. Update the version number.
> 2. Fixup code style error.
> 3. Separate qemu code into single patch.
> 4. Rebase the patches to the new code of master branch.
> 
> v3->v4:
> 1. Update docs.
> 2. Format code style.
> 3. Optimize zPCI support check.
> 4. Move the check of zPCI defined in xml but unsupported by Qemu to
>     qemuDomainDeviceDefValidate().
> 5. Change zpci address member of PCI address struct from pointer to
>     instance.
> 6. Modify zpci address definition principle. Currently the user must
>     either define both of uid and fid or not.
> 
> v2->v3:
> 1. Revise code style.
> 2. Update test cases.
> 3. Introduce qemuDomainCollectPCIAddressExtension() to collect PCI
>     extension addresses.
> 4. Introduce virDeviceInfoPCIAddressExtensionPresent() to check if zPCI
>     address exists.
> 5. Optimize zPCI address check logic.
> 6. Optimize passed parameters of zPCI addr alloc/release/reserve functions.
> 7. Report enum range error in qemuDomainDeviceSupportZPCI().
> 8. Update commit messages.
> 
> v1->v2:
> 1. Separate test commit and merge testcases into corresponding commits that
>     introduce the functionalities firstly.
> 2. Spare some checks for zpci device.
> 3. Add vsock and controller support.
> 4. Add uin32 type schema.
> 5. Rename zpciuid and zpcifid to zpci_uid and zpci_fid.
> 6. Always return multibus support on S390.
> 
> Yi Min Zhao (13):
>    conf: Add definitions for 'uid' and 'fid' PCI address attributes
>    qemu: Introduce zPCI capability
>    conf: Introduce a new PCI address extension flag
>    qemu: Enable PCI multi bus for S390 guests
>    qemu: Auto add pci-root for s390/s390x guests
>    conf: Introduce address caching for PCI extensions
>    conf: Introduce parser, formatter for uid and fid
>    qemu: Add zPCI address definition check
>    conf: Allocate/release 'uid' and 'fid' in PCI address
>    qemu: Generate and use zPCI device in QEMU command line
>    qemu: Add hotpluging support for PCI devices on S390 guests
>    docs: Add 'uid' and 'fid' information
>    news: Update news for PCI address extension attributes
> 
>   cfg.mk                                        |   1 +
>   docs/formatdomain.html.in                     |   9 +-
>   docs/news.xml                                 |  11 +
>   docs/schemas/basictypes.rng                   |  27 ++
>   docs/schemas/domaincommon.rng                 |   1 +
>   src/conf/device_conf.c                        |  90 +++++
>   src/conf/device_conf.h                        |   7 +
>   src/conf/domain_addr.c                        | 332 ++++++++++++++++++
>   src/conf/domain_addr.h                        |  30 ++
>   src/conf/domain_conf.c                        |  14 +-
>   src/libvirt_private.syms                      |   7 +
>   src/qemu/qemu_capabilities.c                  |   6 +
>   src/qemu/qemu_capabilities.h                  |   1 +
>   src/qemu/qemu_command.c                       | 102 ++++++
>   src/qemu/qemu_command.h                       |   2 +
>   src/qemu/qemu_domain.c                        |  39 ++
>   src/qemu/qemu_domain_address.c                | 204 ++++++++++-
>   src/qemu/qemu_hotplug.c                       | 162 ++++++++-
>   src/util/virpci.c                             |   7 +
>   src/util/virpci.h                             |  14 +
>   .../caps_2.10.0.s390x.xml                     |   1 +
>   .../caps_2.11.0.s390x.xml                     |   1 +
>   .../caps_2.12.0.s390x.xml                     |   1 +
>   .../qemucapabilitiesdata/caps_2.7.0.s390x.xml |   1 +
>   .../qemucapabilitiesdata/caps_2.8.0.s390x.xml |   1 +
>   .../qemucapabilitiesdata/caps_2.9.0.s390x.xml |   1 +
>   .../qemucapabilitiesdata/caps_3.0.0.s390x.xml |   1 +
>   .../disk-virtio-s390-zpci.args                |  26 ++
>   .../disk-virtio-s390-zpci.xml                 |  19 +
>   .../hostdev-vfio-zpci-autogenerate.args       |  25 ++
>   .../hostdev-vfio-zpci-autogenerate.xml        |  18 +
>   .../hostdev-vfio-zpci-boundaries.args         |  29 ++
>   .../hostdev-vfio-zpci-boundaries.xml          |  30 ++
>   .../hostdev-vfio-zpci-multidomain-many.args   |  39 ++
>   .../hostdev-vfio-zpci-multidomain-many.xml    |  79 +++++
>   tests/qemuxml2argvdata/hostdev-vfio-zpci.args |  25 ++
>   tests/qemuxml2argvdata/hostdev-vfio-zpci.xml  |  21 ++
>   tests/qemuxml2argvtest.c                      |  20 ++
>   .../disk-virtio-s390-zpci.xml                 |  31 ++
>   .../hostdev-vfio-zpci-autogenerate.xml        |  34 ++
>   .../hostdev-vfio-zpci-boundaries.xml          |  48 +++
>   .../hostdev-vfio-zpci-multidomain-many.xml    |  97 +++++
>   .../qemuxml2xmloutdata/hostdev-vfio-zpci.xml  |  32 ++
>   tests/qemuxml2xmltest.c                       |  17 +
>   44 files changed, 1648 insertions(+), 15 deletions(-)
>   create mode 100644 tests/qemuxml2argvdata/disk-virtio-s390-zpci.args
>   create mode 100644 tests/qemuxml2argvdata/disk-virtio-s390-zpci.xml
>   create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.args
>   create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.xml
>   create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.args
>   create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.xml
>   create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.args
>   create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.xml
>   create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci.args
>   create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci.xml
>   create mode 100644 tests/qemuxml2xmloutdata/disk-virtio-s390-zpci.xml
>   create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate.xml
>   create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-boundaries.xml
>   create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-multidomain-many.xml
>   create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci.xml
> 


-- 
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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list