Re: [PATCH 2/2] iommu: dmar -- reserve mmio space used by IOMMU
From: Don Dutile
Date: Mon Jun 04 2012 - 19:10:09 EST
On 06/04/2012 06:37 PM, David Woodhouse wrote:
On Mon, 2012-06-04 at 17:29 -0400, Donald Dutile wrote:
Intel-iommu initialization doesn't currently reserve the memory used
for the IOMMU registers. This can allow the pci resource allocator
to assign a device BAR to the same address as the IOMMU registers.
This can cause some not so nice side affects when the driver
ioremap's that region.
s/affect/effect/
ok.
And surely this can happen even when IOMMU support is compiled out of
the kernel. Shouldn't the BIOS be *telling* us that this region is
unavailable for PCI resource allocation (or anything else, for that
matter)?
good point....
If the BIOS *doesn't* do that, then I believe this should be
WARN_TAINT_ONCE(âTAINT_FIRMWARE_WORKAROUNDâ) like other BIOS problems
that we have discovered.
well, one could argue it may be easier to claim the space reserved in
the OS then making yet another hole in the available IO address space
in the ACPI tables. Although I think the workarounds more systems
implement is to stick the IOMMUs into an existing hole to avoid this problem.
And we should probably do it based on the actual chipset registers, not
the DMAR tables (which the BIOS has also been known to lie about).
but.... the DMAR tables are the source of all information.... wise and ... er, um... ;-)
yes, I've been on the receiving side of more bz's wrt bad DMAR tables then I can count,
but...
How does the kernel probe for chipsets, then registers with the chipsets
to find the programmed IOMMU BAR values?
-- I missed that class.... I only have Intel Virt Tech Directed I/O
Architecture spec., and the beginning of IOMMU is based on DMAR tables...
If you have more info/guidance, I'd appreciate it.
Seems like the patch would be easier to support, although it doesn't
solve the problem you mentioned above, unless the reservation code isn't
compiled out by INTEL-IOMMU (but something more general like !(x86 && PCI)).
the firmware taint message would be informative as to the quality of
the firmware, but my experience is nothing changes unless it's critical
to a system shipping.
IMO, if we can avoid a BIOS problem, we should.
The empirical data I've gathered so far in this space
(IOMMU, use by SRIOV VF devices), shows the BIOS has numerous
weaknesses, and this is yet another one. The BIOS's are getting better,
but I've seen turtles run faster... ;-) .
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/