Message-ID: <4FCD4A5B.2050604@redhat.com>
Date:	Mon, 04 Jun 2012 19:52:59 -0400
From:	Don Dutile <ddutile@...hat.com>
To:	David Woodhouse <dwmw2@...radead.org>
CC:	iommu@...ts.linux-foundation.org, mingo@...e.hu,
	linux-kernel@...r.kernel.org, chrisw@...hat.com,
	suresh.b.siddha@...el.com
Subject: Re: [PATCH 2/2] iommu: dmar -- reserve mmio space used by IOMMU

On 06/04/2012 07:23 PM, David Woodhouse wrote:
> 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.
>
ok.

>> 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...
>
except that quirk is conditionally compiled in intel-iommu.c;
to do the check indep of INTEL-IOMMU CONFIG tag, it'd have to move into
pci/quirks.c. ... and how does it get triggered? ... a dmar table check?
(typical quirks kicked based on vid/did...)

> 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.
>
The 'do it for intel-iommu systems only' and not be CONFIG dependent
is a bit challenging given how the code is compiled, and the expected/normal
code flow starting from a dmar table.
of course, if the IOMMU just exposed itself as the first device on a PCI
bus, this would be trivial!
-- I really hate BIOS dependencies to get things right!

>> 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.
>
>
except, most system (hw, os, applic) certifications are based on vendor's
shipped BIOS, so Coreboot isn't a guarantee either.  Additionally, telling
a customer to replace their paid-for-BIOS for a build-your-own-coreboot bios
is a tough way to close a bz. ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists