On Fri, 2018-10-19 at 11:40 +0800, Yi Min Zhao wrote: > Abstract > ======== > The PCI representation in QEMU has 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. So, I was able to sit down with Laine during KVM Forum and we looked over the entire series together. He didn't spot any issues with it except for the couple minor ones that I pointed out separately in response to the corresponding patches; as for myself, I've already provided R-bs for all patches and I have no further objections to this being merged. I also asked Dan to weigh in explicitly on the list regarding his concerns about the XML design, and he promised he'd do that... I think you can post a v8 which addresses the small issues mentioned above (and rebased on top of current master) in the meantime. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
