Bug 967231 - RFE: capabilities: provide info about host VT-D/AMD-Vi IOMMU support
Summary: RFE: capabilities: provide info about host VT-D/AMD-Vi IOMMU support
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard: LibvirtFirstBug
: 885400 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-25 20:36 UTC by Cole Robinson
Modified: 2018-06-10 07:28 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-10 07:28:05 UTC
Embargoed:


Attachments (Terms of Use)

Description Cole Robinson 2013-05-25 20:36:16 UTC
Whether a PCI device can be successfully assigned to a guest seems to depend on a lot of factors, for example PCI vs. PCIe and MSI bits listed at the end of this page: http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM
VFIO also limitations depending on what iommu_group and device is in. I'm sure there is other bits as well.

Unfortunately apps have no real way of determining if a device is PCI assignable or not because libvirt doesn't provide enough information here. I imagine some of the above bits could be exposed in nodedev XML, or the logic is kept in libvirt and just expose an 'assignable' value, but things probably don't boil down to a nice boolean value like that.

libvirt should also expose whether a host is vt-d/amd-vi capable.

Comment 1 Cole Robinson 2013-10-09 18:08:08 UTC
Reporting iommu_group is in git nowadays, but not the rest that I can see.

Comment 2 Cole Robinson 2013-10-31 20:03:20 UTC
The rules for PCI vs PCIe and MSI vs MSI-x seem pretty subtle, and I'm thinking now that apps shouldn't be in the business of trying to predict those bits, so dropping from the request. But VT-D/AMD-Vi availability reporting would still be useful

Comment 3 Cole Robinson 2013-11-17 20:33:22 UTC
*** Bug 885400 has been marked as a duplicate of this bug. ***

Comment 4 Cole Robinson 2016-03-21 14:19:32 UTC
Adding some additional info for LibvirtFirstBug:

To implement this you'll need to:

* extend the capabilities XML to add a new element like <iommu present="on"/> in the <capabilities><host> block. The XML handling is in src/conf/capabilities.c
* add a function to src/nodeinfo.c for probing the host to determine if IOMMU is present. you can get the IOMMU probing logic from tools/virt-host-validate-common.c:virHostValidateIOMMU ; either copy it or find a way to share it between the two.
* wire it all up so that at least the qemu HV driver will fill in the info in capabilities XML

See this commit for an example of extending capabilities XML with new data: https://github.com/libvirt/libvirt/commit/02129b7c0e581898f03468e0bfb5472dc9903339

Comment 5 Michal Privoznik 2018-06-10 07:28:05 UTC
Patches are now merged upstream:

commit 6549c3a4d10bd895a7ac4283af933951dde4c86d
Author:     Filip Alac <filipalac>
AuthorDate: Fri Jun 1 10:16:00 2018 +0200
Commit:     Michal Privoznik <mprivozn>
CommitDate: Tue Jun 5 09:11:29 2018 +0200

    docs: news: Explain iommu_support improvement
    
    Signed-off-by: Filip Alac <filipalac>

commit dc34e78e21d64b8b43e627c4d2e8646ca7bfb5e5
Author:     Filip Alac <filipalac>
AuthorDate: Fri Jun 1 10:15:59 2018 +0200
Commit:     Michal Privoznik <mprivozn>
CommitDate: Tue Jun 5 08:33:13 2018 +0200

    capabilities: Extend capabilities with iommu_support
    
    Signed-off-by: Filip Alac <filipalac>
    Signed-off-by: Michal Privoznik <mprivozn>

commit 1597e155b2ea94d8cf27b23cab116febbf86cf82
Author:     Filip Alac <filipalac>
AuthorDate: Fri Jun 1 10:15:58 2018 +0200
Commit:     Michal Privoznik <mprivozn>
CommitDate: Tue Jun 5 08:33:13 2018 +0200

    qemu: hostdev: Move parts of qemuHostdevHostSupportsPassthroughVFIO() into separate function
    
    Signed-off-by: Filip Alac <filipalac>
    Signed-off-by: Michal Privoznik <mprivozn>

v4.4.0-86-g6549c3a4d1


Note You need to log in before you can comment on or make changes to this bug.