Thanks. Like I mentioned before, the system object has always managed physical memory in SE mode, so this patch doesn't really affect that anyway. Also, I would argue that to the extent any object manages physical addresses in FS mode, it's the system object there too, so there's no inconsistency. It's just that the only physical address management task that exists in the simulator in FS mode currently is to figure out the range of valid physical addresses, so it can tell the target OS about it... and isn't it the system object that does that?
Steve On Sat, Oct 22, 2011 at 9:57 PM, Gabe Black <[email protected]> wrote: > The only thing I think I'm concerned about is that the system object is > managing the physical address space in SE mode but not in FS. It seems > appropriate for it to, though, so I'll have to figure out some way to > get it to all fit together nicely later, maybe with a subclass. Go ahead > and push. > > Gabe > > On 10/22/11 16:57, Steve Reinhardt wrote: > > So do you mind if I push this, Gabe? Or do you have further questions or > > concerns? > > > > Steve > > > > On Fri, Oct 21, 2011 at 2:40 PM, Steve Reinhardt <[email protected]> > wrote: > > > >> > >> On Fri, Oct 21, 2011 at 2:15 PM, Gabriel Michael Black < > >> [email protected]> wrote: > >> > >>> Ok, so the new API is that the system manages physical pages, the > process > >>> manages virtual pages, the page table glues them together, and there > is/are > >>> function(s) on the process object which tie it all together? > >> > >> For the most part, this isn't really new... the system has always > managed > >> physical pages, the process has always managed virtual addresses, and > the > >> page table has always managed mappings. (Though the process "manages" > >> virtual address mostly by making its variables like mmap_start and > mmap_end > >> public and letting whoever wants to muck with them.) > >> > >> The problem is that before the page table didn't deal only with > mappings, > >> it also had this ungainly "allocate()" method that dealt with both > mappings > >> and physical pages; I'm just cleaning it up so that the page table deals > >> *only* with mappings, and if you want to do something that involves both > >> mappings and physical pages, you have to go to the process object, which > is > >> the logical point where you know about both the page table and the > system > >> together. > >> > >> > >>> That makes sense. I'll think about how that fits with the whole > >>> workload/address space thing I'd like to do at some point and how that > extra > >>> level of abstraction would fit, but no problems leap out at me. > >>> > >> It's not an extra level of abstraction, from my perspective, it's just > >> cleaning up some code that didn't properly obey existing conceptual > >> boundaries. I don't know if it will interfere with what you're doing > >> practically, but conceptually I can't see how it could do anything but > make > >> life easier, as it decouples two objects that were previously coupled. > >> > >> > >>> I'll have to look at the pid thing and remind myself what it's used > for. > >>> Maybe we can get rid of it too. > >> > >> It's just used to populate the TLB entry... my guess is that it might > >> matter in cases where you have multiprogrammed workloads running on an > SMT > >> core where threads from different address spaces have to share a TLB. > >> > >> Steve > >> > >> > >> > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
