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

[Don Dutile]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/