[Kimchi-devel] [PATCH v7 2/4] Host device passthrough: List eligible device to passthrough

Zhou Zheng Sheng zhshzhou at linux.vnet.ibm.com
Mon Jul 14 02:44:04 UTC 2014


on 2014/07/13 22:43, Aline Manera wrote:
> On 07/09/2014 04:01 AM, Zhou Zheng Sheng wrote:
>> This patch adds a '_passthrough=true' filter to /host/devices, so it can
>> filter and shows all devices eligible to passthrough to guest.
>> Theoretically, all PCI, USB and SCSI devices can be assigned to guest
>> directly. However usually all host devices form a tree, if we assign a
>> PCI port/SCSI controller/USB controller to guest, all devices/disks
>> under the controller are assigned as well. In this patch we only present
>> the "leaf" host devices to the user as potential passthrough devices.
>> In other word, the possible devices are wireless network interface, SD
>> card reader, camera, SCSI unit(disk or CD), and so on.
>>
>> Linux kernel is able to recognize the host IOMMU group layout. If two
>> PCI devices are in the same IOMMU group, it means there are possible
>> interconnections between the devices, and the devices can talk to each
>> other bypassing IOMMU. This implies isolation is not pefect between those
>> devices, so all devices in a IOMMU group must be assigned to guest
>> together. On host that recognizes IOMMU groups, by accessing the URI
>> /host/devices/deviceX/passthrough_affected_devices, it returns a list
>> containing the devices in the same IOMMU group as deviceX.
>>
>> How to test:
>>
>> List all types of devices to passthrough
>>    curl -k -u root -H "Content-Type: application/json" \
>>      -H "Accept: application/json" \
>>      'https://127.0.0.1:8001/host/devices?_passthrough=true'
>>
>> List all eligible PCI devices to passthrough
>>    /host/devices?_passthrough=true&_cap=pci
>>
>> List all USB devices to passthrough
>>    /host/devices?_passthrough=true&_cap=usb_device
>>
>> List all SCSI devices to passthrough
>>    /host/devices?_passthrough=true&_cap=scsi
>>
>> List devices in the same IOMMU group as pci_0000_00_19_0
>>    /host/devices/pci_0000_00_19_0/passthrough_affected_devices
> 
> This passthrough_affected_devices seems a filter instead of a new resource.
> 
> Couldn't we do: /host/devices/pci_0000_00_19_0?_passthrough=true ?
>

Thanks Aline. Let me explain why I don't think it's a filter.

/host/devices/pci_0000_00_19_0 is a particular device, it contains
information like vendor and product id/name, device sysfs patch, domain,
bus, slot function id. All these are simple attributes of this device.
The affected devices are a collection containing all devices in the same
iommu group as pci_0000_00_19_0. If you think a new sub-collection is
not good. I propose using a filter for /host/devices. For example,

/host/devices?_passthrough_group_by=pci_0000_00_19_0

>>
>> v1:
>>    v1 series does not contain this patch.
>>
>> v2:
>>    Deal with calculation "leaf" device and "affected" device.
>>
>> v3 v4:
>>    No change.
>>
>> v5:
>>    Change _passthrough=1 to _passthrough=true in the URI scheme. Filter
>> PCI devices according the PCI class.
>>
>> v6:
>>    Don't passthrough PCI device of class code 07. In modern
>> x86 machine, it's possible that
>> "6 Series/C200 Series Chipset Family MEI Controller" and
>> "6 Series/C200 Series Chipset Family KT Controller"
>> are of this class code. These two devices are not suitable to
>> passthrough to guest. We don't have simple and reliable way to
>> distinguish normal serial controller and host chipset XXX controller.
>> This type of PCI devices also include various serial, parallel, modem,
>> communication controller. Serial and parallel controllers can be
>> re-direct from ttyS0 to QEMU's pty using socat, and there is little
>> performance benefit to directly assign to guest. So it'k ok not to
>> passththrough PCI device of class code 07.
>>
>> Signed-off-by: Zhou Zheng Sheng <zhshzhou at linux.vnet.ibm.com>

Didn't find more comments below, so I truncate the mail.

-- 
Zhou Zheng Sheng / 周征晟
E-mail: zhshzhou at linux.vnet.ibm.com
Telephone: 86-10-82454397




More information about the Kimchi-devel mailing list