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

[Xen-users] Disbale IGD IOMMU to allow DMA Pass Through on other IOMMU?



While looking into the degree of Vt-d support provided by my CPU
(i5-3317U w/ Ivy Bridge), I noticed that the two IOMMUs, one for the
IGD and the other for the remaining devices, do not have the same
capabilities.  Xen reports an ecap value of 0xf0101a for the first and
0xf0105a for the second.  The 0x000040 bit for the second IOMMU
support for DMA Pass Through.  The CPU datasheet also says the Snoop
Control bit, 0x000080, is on after a reset, but it is disabled by the
time Xen is booting on my MacBook Air. The CPU datasheet lists this
bit as "RO-V" (read-only volatile), but I do not know what volatilizes
it.

It appears the Xen developers have expressly opted for a least common
denominator approach for IOMMU capabilities, where if a feature not
not supported by ALL of the IOMMUs, it is not available for any of the
IOMMUs.  See intel_vtd_setup() in vtd/iommu.c, for example.

However, it also appears that there were enough buggy Sandy Bridge
implementations that there is code in quirks.c directed to disabling
the IGD IOMMU while making use of the other one.  Assumedly the Intel
HD 3000 and 4000 architectures are similar enough that one could
similarly disable the IGD IOMMU for Ivy Bridge.

I have a two questions in connection with this:

1) Assuming only dom0 is using the IGD (which means it is not being
passed through to a domU), and the IGD IOMMU is left unused, does this
degrade the isolation between the domU's and dom0 and/or the IGD?
Does it matter if the domU is PV?

2) Does Pass Through provide a tangible improvement in performance
(e.g., is it worth trying to do this)?

Thank you,
Eric

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.