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

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

 





在 2018/7/17 下午8:35, Cornelia Huck 写道:
On Tue, 10 Jul 2018 16:02:14 +0800
Yi Min Zhao <zyimin@xxxxxxxxxxxxx> 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.


Thanks! Libvirt developers have not given any comment on v2 until now.
I'm afraid the end of this month is coming soon.

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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux