* David Woodhouse <[email protected]> wrote:
> > 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.
So basically the patch-set is fine as-is, we just want a
sufficiently nasty sounding warning message about the BIOS bug,
with actionable output, something like:
... the kernel is sad because a buggy BIOS has not
marked IOMMU area xxx-yyy as reserved, working
it around. You get to keep all the pieces and
be more careful with remaining eye.
(or a functional equivalent thereof.)
this patch could be added as a third patch in the series, right?
> > 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.
If we could integrate Coreboot into the kernel and could build a
bzImage that one could write into the BIOS flash image and thus
have an updated and functional BIOS, that would be awesome.
People could actually write systems with proper 'every pixel is
perfect' boot output and low latency behavior from the moment
power is turned on to the first desktop GUI frame and such.
(With some fail safe mechanism for bugs.)
And ponies.
Thanks,
Ingo
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
