Messages in this thread | | | Subject | Re: [PATCH 2/2] iommu: dmar -- reserve mmio space used by IOMMU | From | David Woodhouse <> | Date | Tue, 05 Jun 2012 00:23:16 +0100 |
| |
On Mon, 2012-06-04 at 19:09 -0400, Don Dutile wrote: > > 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.
But how? It's got to work with operating systems that predate the IOMMU. The registers *have* to be in a marked hole. If *not*, then we should give a clear "YOUR BIOS IS BROKEN" output like all the similar breakages, and do our best to work around it.
Working around it is fine; I'm not suggesting that we should WARN() *instead* of working around it.
> 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.
Hm, I thought we'd already started doing some of that in order to sanity-check the DMAR tables. The VTBAR registers are in PCI config space. The quirk_ioat_snb_local_iommu() check is already looking at them...
I'm not quite sure which document they are documented in. Doing it based on the DMAR table, as you have, is certainly a good start. But do it with a bigger shouty WARN(TAINT_FIRMWARE_WORKAROUND), and do it when the IOMMU code isn't compiled in.
> 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.
> The BIOS's are getting better, but I've seen turtles run faster... ;-) .
Thankfully, there are now some modern Intel systems on which you can run Coreboot. This should be a huge benefit — you should be able to build an up-to-date Tianocore and deploy it as your Coreboot payload, rather than having to put up with the crap that's on the system when you receive it.
-- dwmw2 [unhandled content-type:application/x-pkcs7-signature] | |