On 11/12/2013 06:14 PM, Paul B. Henson wrote: >> From: Richard Yao [mailto:[email protected]] >> Sent: Tuesday, November 12, 2013 9:00 AM >> >> I recompiled my kernel with support and I now see some rather reassuring >> messages in dmesg about an IOMMU being used for various devices. It is > > To clarify, do you mean CONFIG_INTEL_IOMMU and > CONFIG_INTEL_IOMMU_DEFAULT_ON? It would appear the former is generally > configured on the average distribution, but not the latter, requiring an > explicit kernel parameter to be supplied at boot in order to enable it. > >> not clear to me that Linux distributions ship with this enabled, >> although that is a concern for ZFSOnLinux and various Linux >> distributions. I will patch Gentoo's genkernel software to add support >> for this functionality by default. > > So you are going to enable CONFIG_INTEL_IOMMU_DEFAULT_ON in the default > Gentoo kernel config from now on?
Gentoo does not actually provide users with a prebuilt kernel. Instead, we provide them with source code and asks them to compile it by hand. However, we do have software called genkernel that will automate the build process and provide a kernel config with sane defaults should the user have not provided his own. I was planning to patch gernkenel to toggle this feature on by default. However, I think I will consult the Gentoo kernel team about the wisdom of this before touching it in genkernel. The Gentoo kernel and genkernel teams are separate. >There was a mention of a similar feature > in FreeBSD, I'm not sure if it changed since this posting discussing it: > > http://lists.freebsd.org/pipermail/freebsd-arch/2013-May/014368.html > > " It is known that IOMMU adds overhead due to the mapping and unmapping > for each I/O. DMAR implementations usually have some erratas, as well > as PCIe devices sometime do not completely follow the specification, > causing misbehaviour with remapping enabled. For this reason I do not > plan to enable IOMMU by default" I am inclined to expect that buggy drivers to be the main cause of problems. Specifically, ones that either do not inform the kernel of the addresses that they are using or assume that the addresses that the device uses are identical to those in the kernel address space. Using an IOMMU to restrict devices to the addresses viewed by the kernel would circumvent the latter problem while the former is a rather serious driver bug that would be squashed rather quickly once the IOMMU reveals it. I am not sure how devices would be able to tell that the memory addresses they are using have been virtualized, but I admit ignorance of the PCIe protocol. Do you know of any examples of devices that deviate from the specification in such a way that they have compatibility problems? A single example could present me with the opportunity to understand how a PCIe device itself can be incompatible with an IOMMU. > but at the time it sounds like they weren't going to enable it by default, > which would make it similar to the current average linux kernel, which > supports it, but doesn't enable it by default? I suspect that CONFIG_INTEL_IOMMU_DEFAULT_ON is the exception, rather than the rule. Other IOMMU providers (specifically AMD) do not appear to have a *_DEFAULT_ON option, which suggests to me that the default is to toggle them on when support is available. > Any idea what the performance impact of the overhead is? I do not know. It would be nice to quantify the actual impact, but I am inclined to consider the benefits and performance impact of an IOMMU to be analogous to those of a traditional MMU. i.e. the reliability gains outweigh the performance loss. I suspect that adoption of virtual memory protection from IOMMUs is inevitable, much like how adoption of virtual memory protection from MMUs was. > Or how many DMAR implementations are buggy :)? I have no clue, but I would like to see an example of 1 buggy DMAR implementation before thinking about how prevalent they are. That being said, errata happen, but I think that errata should be handled on a case-by-case basis like they always have been.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
