Re: [libvirt] [PATCH v2 RESEND 00/12] PCI passthrough support on s390

On Tue, 10 Jul 2018 16:02:14 +0800 Yi Min Zhao <zyimin(a)linux.ibm.com&gt; 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, two new XML > attributes, @uid and @fid, are introduced for device addresses of type > 'pci', i.e.: > <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' > uid='0x0003' fid='0x00000027'/> > </hostdev> > > uid and fid are optional attributes. 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. > > Current implementation is the most seamless one for the user as it > unites the address specific data of a PCI device on one XML element. > It could accommodate both specifying our special parameters (uid and fid) > and re-using standard statements (domain, bus, slot and function) for > PCI devices. User can still specify bus/slot/function for the virtualized > PCI devices in the XML. > > Thus uid/fid act as an extension to the PCI address and 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 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. FWIW, from my QEMU POV there's nothing obviously wrong in here, but I'm not familiar with the libvirt code base. So I'll leave this to the libvirt developers.