diff options
author | Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> | 2013-09-27 10:11:49 +0200 |
---|---|---|
committer | Jan Beulich <jbeulich@suse.com> | 2013-09-27 10:11:49 +0200 |
commit | 0af438757d455f8eb6b5a6ae9a990ae245f230fd (patch) | |
tree | 2c522f2098841db0e8a22f87bfe132b3cf6d68cd /unmodified_drivers | |
parent | 1aac966e24e92d664089cfa075f21bbb570a7d58 (diff) | |
download | xen-0af438757d455f8eb6b5a6ae9a990ae245f230fd.tar.gz xen-0af438757d455f8eb6b5a6ae9a990ae245f230fd.tar.bz2 xen-0af438757d455f8eb6b5a6ae9a990ae245f230fd.zip |
AMD IOMMU: fix Dom0 device setup failure for host bridges
The host bridge device (i.e. 0x18 for AMD) does not require IOMMU, and
therefore is not included in the IVRS. The current logic tries to map
all PCI devices to an IOMMU. In this case, "xl dmesg" shows the
following message on AMD sytem.
(XEN) setup 0000:00:18.0 for d0 failed (-19)
(XEN) setup 0000:00:18.1 for d0 failed (-19)
(XEN) setup 0000:00:18.2 for d0 failed (-19)
(XEN) setup 0000:00:18.3 for d0 failed (-19)
(XEN) setup 0000:00:18.4 for d0 failed (-19)
(XEN) setup 0000:00:18.5 for d0 failed (-19)
This patch adds a new device type (i.e. DEV_TYPE_PCI_HOST_BRIDGE) which
corresponds to PCI class code 0x06 and sub-class 0x00. Then, it uses
this new type to filter when trying to map device to IOMMU.
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Reported-by: Stefan Bader <stefan.bader@canonical.com>
On VT-d refuse (un)mapping host bridges for other than the hardware
domain.
Coding style cleanup.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
Diffstat (limited to 'unmodified_drivers')
0 files changed, 0 insertions, 0 deletions