> -----Original Message----- > From: Marc Jones [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 02, 2008 7:52 PM > To: Myles Watson > Cc: ron minnich; Rudolf Marek; Coreboot > Subject: Re: [coreboot] Resource Allocation discussion > > On Tue, Dec 2, 2008 at 3:23 PM, Myles Watson <[EMAIL PROTECTED]> wrote: > > > > > >> -----Original Message----- > >> From: ron minnich [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, December 02, 2008 2:51 PM > >> To: Myles Watson > >> Cc: Marc Jones; Rudolf Marek; Coreboot > >> Subject: Re: [coreboot] Resource Allocation discussion > >> > >> On Tue, Dec 2, 2008 at 11:33 AM, Myles Watson <[EMAIL PROTECTED]> > wrote: > >> > >> > Do we want to take fixed resources into account in the allocator? > >> > >> I would think so. > > > > I would too, but v2 didn't and did pretty well. I'm interested to see > an > > idea for the resource allocation algorithm that allocates from largest > to > > smallest resource, except when it's skipping fixed resources. > > > > I think it's doable, but nothing like what we have. > > That surprises me. I thought it does, which is how/why you can get rid > of DEVICE_MEM_HIGH. Otherwise you would clobber the ROM and the APIC.
You're right. I think it's broken. That's why right now I'm setting the base to 0xfc000000 manually. Thanks for pointing it out. I'd assumed that resource_max took fixed resources into account, but it doesn't. All resource_max does is align the resource based on its limit. So maybe we need to traverse the tree looking for fixed spaces, and constrain the domain's resource limit and base. That wouldn't be too hard. What I was saying would be hard is interleaving fixed resources with movable resources. In other words, if we put the VGA ROM between the two APIC allocations to save space. I think that's too ugly. I'll add a traversal to the tree that doesn't ignore fixed resources. > And that brings up where to reserve the ROM space. In the southbridge > subtractive device code I guess? Sure. How much do we reserve? Is it southbridge dependent? Thanks, Myles -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
