Re: [PATCH 2/2] iommu: dmar -- reserve mmio space used by IOMMU

From: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: Don Dutile <ddutile-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: chrisw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	suresh.b.siddha-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	mingo-X9Un+BFzKDI@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 2/2] iommu: dmar -- reserve mmio space used by IOMMU
Date: Tue, 05 Jun 2012 00:23:16 +0100	[thread overview]
Message-ID: <1338852196.26785.10.camel@shinybook.infradead.org> (raw)
In-Reply-To: <4FCD401D.9000304-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

[-- Attachment #1.1: Type: text/plain, Size: 2355 bytes --]

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

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]

[-- Attachment #2: Type: text/plain, Size: 190 bytes --]

_______________________________________________
iommu mailing list
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu