[coreboot] Resource Allocator for v3

Myles Watson mylesgw at gmail.com
Mon Nov 24 17:22:53 CET 2008


On Mon, Nov 24, 2008 at 9:15 AM, ron minnich <rminnich at gmail.com> wrote:

> On Mon, Nov 24, 2008 at 7:01 AM, Myles Watson <mylesgw at gmail.com> wrote:
>
> >                if (resource->flags & IORESOURCE_IO) {
> >                        /* Don't allow potential aliases over the legacy
> PCI
> >                         * expansion card addresses. The legacy PCI
> decodes
> >                         * only 10 bits, uses 0x100 - 0x3ff. Therefore,
> only
> >                         * 0x00 - 0xff can be used out of each 0x400 block
> > of
> >                         * I/O space.
> >                         */
> >                        if ((base & 0x300) != 0) {
> >                                base = (base & ~0x3ff) + 0x400;
> >                        }
> >                        /* Don't allow allocations in the VGA I/O range.
> >                         * PCI has special cases for that.
> >                         */
> >                        else if ((base >= 0x3b0) && (base <= 0x3df)) {
> >                                base = 0x3e0;
> >                        }
> >                }
> >
> > It seems like I'm misreading this and/or the check isn't broad enough.
>  If
> > there are really devices claiming all IO where the last 10 bits decode to
> > 0x300, then many more ranges should be affected.  For example, a size
> 0x200
> > allocation from 0x200-0x3ff doesn't trigger this check.  Neither does a
> size
> > 0x200 allocation from 0x1200 - 0x13ff, but a size 0x20 allocation from
> > 0x1320-0x133f does.
>
> I don't understand. 0x200 & 0x300 is non-zero. 0x200 will trigger it.


You're right.  I didn't put that example together well.  What I was trying
to say was a resource allocation that covers that range but doesn't have its
base address in the range.  Maybe I won't mess up a simpler example:

An allocation of size 0x400 from 0x0 - 0x3ff.  The allocation has several
addresses within it that have problems with the legacy decode, but doesn't
get caught because the base doesn't trigger the check.  Same with 0x1000 -
0x13ff.

Thanks,

Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081124/456bf540/attachment.html>


More information about the coreboot mailing list