Basically, the e820 map is to tell the OS what areas of memory it can use and what areas hold the BIOS itself and the data tables it needs to operate. There are some areas in higher addresses which I'm not sure what they're for, but I suspect it's something to do with PCI devices or bridges or something. This is for physical memory in the host. Also, the map shows the OS what the highest physical address is it can expect to use. There are other BIOS mechanisms for determining that if you want to call into them, but they're OLD and have maximum return values like 16 MB.
The reason I'd want to enumerate children is so I can find any memory objects below the CPU and determine what available ranges I can add into the map. If there ends up being in-memory-system address transformation in the future that could be more complicated, but for now just getting a list of accessible children would work. If, for some reason, somebody hooks up a sparse address space, it would be ideal to be able to find all the memory banks and put in a region for each of them. That would again be more complicated if there was some mechanism to get at memory that isn't a memory object child of that system, like for instance NUMA with nodes over an ethernet network, but it would be close enough for most cases I think. Gabe nathan binkert wrote: > I'm not clear on exactly what you're doing here. Why is the area > reserved? Are you talking about physical memory on the host? Why do > you need to enumerate children? Details... > > Nate > > On Sat, May 3, 2008 at 8:27 AM, Gabe Black <[EMAIL PROTECTED]> wrote: >> I'm back in Ann Arbor waiting for my brother's surgery and I haven't had >> a chance to go back and get my desktop to work from, so I'm fiddling >> around with trying to get this to work. What I'm thinking to do is >> basically to just make the places I stick BIOS tables reserved and >> everything else up to the memory available available. That requires >> figuring out how much physical memory is in the system on the fly from >> the configuration script. Ideally it could also figure out sparsely >> populated address spaces. I know there's a way to look for the first >> -parent- that matches a particular type, but is there a way to enumerate >> all the children similarly? What are all the types of memory we support? >> I'm aware of a basic physical memory and a DRAM model. Maybe those >> should have an underlying base type to make it easier to find them all? >> >> Gabe >> >> >> >> Gabe Black wrote: >> > I agree. This is something I plan to do once I get, for instance, a bash >> > shell working just so I can have a mostly known working entity to start >> > from and to cut down on where problems could be from. I'm going to have >> > to spend some time in Edwardsburg (my parent's house) because of a >> > family emergency so I brought my desktop back with me. I can work on >> > that machine which won't have a problem with allocating 4 gigs until I >> > make that configurable.. >> > >> > Gabe >> > >> > nathan binkert wrote: >> >> There's also a kernel command line option to override the bios notion >> >> of how much ram there is. Did you try that? No matter what you do, >> >> you must come up with a way to make the amount of memory configurable. >> >> >> >> On Sat, Apr 26, 2008 at 10:00 PM, Gabe Black <[EMAIL PROTECTED]> wrote: >> >>> Well, it's not really just a value, it's a table of regions that are >> >>> reserved or not. I'm not sure exactly how the regions are identified >> and >> >>> I'd probably have to do a bunch of digging to figure out how to >> >>> generate one. I think I'll just wait until I get back up to UM and use >> >>> my desktop and avoid the whole problem. >> >>> >> >>> Gabe >> >>> >> >>> >> >>> >> >>> Ali Saidi wrote: >> >>> > We talked about doing precisely that several years ago. You can also >> >>> > then compress the individual pages and also hash them so that you >> only >> >>> > need one copy of any page that's replicated. There is a probably a >> >>> > flyspray task to do just that, but no one got around to doing it. In >> the >> >>> > short term though I agree with Steve, just change the value in the >> BIOS. >> >>> > >> >>> > Ali >> >>> > >> >>> > On Apr 26, 2008, at 5:46 PM, Gabe Black wrote: >> >>> > >> >>> >> To pass some time just now I went to try to figure out what seems >> >>> >> like a fairly simple x86 bug on my laptop from my parent's house. It >> >>> >> didn't work because my simulation wants to use 4 gigs of memory, >> and my >> >>> >> laptop is 32 bit and can't fit that into m5's address space. The >> memory >> >>> >> needs to be that large because of some information the BIOS provides >> >>> >> which I copied from a different machine and which tells the kernel >> >>> >> that's how much memory it should expect. Anyway, it seems like >> this, or >> >>> >> something like it, would be an annoying limitation on the simulated >> >>> >> system which depends on the guest. >> >>> >> >> >>> >> I read in a book I have about the linux virtual memory manager >> that >> >>> >> there's some sort of mechanism for mmapping a part of a file at a >> time >> >>> >> into a process, but unfortunately I don't remember the details. >> >>> >> Something like that combined with some M5 level version of paging >> in and >> >>> >> out of the file would get around that limitation. I imagine there >> being >> >>> >> a different memory object (BigPhysical or something like that) to >> keep >> >>> >> the complication out when it isn't needed. Anyway, what does >> everybody >> >>> >> think? >> >>> >> >> >>> >> Gabe >> >>> >> _______________________________________________ >> >>> >> m5-dev mailing list >> >>> >> m5-dev@m5sim.org >> >>> >> http://m5sim.org/mailman/listinfo/m5-dev >> >>> >> >> >>> > >> >>> > _______________________________________________ >> >>> > m5-dev mailing list >> >>> > m5-dev@m5sim.org >> >>> > http://m5sim.org/mailman/listinfo/m5-dev >> >>> >> >>> _______________________________________________ >> >>> m5-dev mailing list >> >>> m5-dev@m5sim.org >> >>> http://m5sim.org/mailman/listinfo/m5-dev >> >>> >> >>> >> >> _______________________________________________ >> >> m5-dev mailing list >> >> m5-dev@m5sim.org >> >> http://m5sim.org/mailman/listinfo/m5-dev >> > >> > _______________________________________________ >> > m5-dev mailing list >> > m5-dev@m5sim.org >> > http://m5sim.org/mailman/listinfo/m5-dev >> >> _______________________________________________ >> m5-dev mailing list >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-dev >> >> > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
