On Tuesday, September 27, 2011, Gabe Black wrote: > Oh, something I forgot to mention. The idea of an address space and how > their managed needs to be generalzed. I'm thinking Workload objects will > have an AddressSpace object associated with them that will take care of > translating from virtual to physical addresses, either by looking up the > page tables in memory in FS mode, or by keeping around fake page tables > in SE mode. >
I'm confused... to me the whole notion of a simulator-visible "address space" concept is an SE-mode artifact that's already handled pretty capably by the PageTable object. Address spaces and page tables in FS mode are managed by the OS running inside the simulator, and are basically invisible to the simulator itself. (The concept leaks through a little in that we do have to implement the TLB and (when appropriate) hardware page-table walker appropriately, and there's the 'vtophys' hook for introspecting into user programs in FS mode, but those are black boxes that don't require the simulator to actually understand what an "address space" is.) If we ever build the fabled "hypervisor emulation" layer then I can see combining these, using the fake PageTable to manage the guest-physical-to-machine mappings while the guest OSes use the current FS mechanisms to manage guest-virtual-to-guest-physical mappings, but that still doesn't require the simulator to understand what a guest virtual address space is. Also I think the PageTable should stay with the Process object and not be part of Workload... if we ever implement fork() in SE mode then we could end up having multiple Process objects (and PageTables) associated with a single Workload. Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
