[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH v7 00/14] PCI passthrough support on s390



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]