> On Aug. 12, 2016, 7:44 a.m., Andreas Hansson wrote: > > src/mem/AbstractMemory.py, line 64 > > <http://reviews.gem5.org/r/3580/diff/4/?file=57455#file57455line64> > > > > I am still trying to wrap my head around what the table looks like with > > in_addr_map, conf_table_Reported, and now kvm_map, for "real memories", > > "device memories", "shadow memories" etc. We technically have 8 different > > types of memories now, but I suspect we only really have three. Could we > > perhaps enumerate them and call that out in the comments. > > > > Perhaps we should consider an enum rather? > > Andreas Sandberg wrote: > A couple of these params are actually orthogonal. At least > conf_table_reported is useful as a separate parameter since there are cases > where you want a memory to be in a part of the address map without being > listed in the DTB/ACPI tables. Now, at least one combination of in_addr_map > and kvm_map is a bit weird. This is what I'd assume that the various > combinations do: > > * in_addr_map && kvm_map: This is well defined, map in KVM & as a > physical memory. > * in_addr_map && !kvm_map: Add to gem5's address map, but not KVM. If > I understand correctly, this is what you need to accomplish for the APU. > * !in_addr_map && kvm_map: Should this be mapped in KVM? I think it'd > make sense not to map it since it's not a part of the global address map. > * !in_addr_map && !kvm_map: Don't map the memory at all. > > Would it ever make sense for a memory to not be in the address map but be > mapped by KVM? I think we should probably make sure KVM doesn't map any > memories that aren't in the address map.
We need both the second and third cases for the APU. The third case for the shadow copy (it isn't in the address map because it overlays the regular copy, but it's copy we need for KVM), and the second case for the regular copy of memory. So I think all four cases are plausible. - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3580/#review8602 ----------------------------------------------------------- On Aug. 5, 2016, 9:37 p.m., David Hashe wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3580/ > ----------------------------------------------------------- > > (Updated Aug. 5, 2016, 9:37 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11562:7375e1f533fa > --------------------------- > cpu, mem, sim: Enable KVM support for Ruby > > Only map memories into the KVM guest address space that are > marked as usable by KVM. > > Remember whether a BackingStoreEntry should be mapped by KVM. > > Fix bug causing incomplete draining of Ruby Sequencer. > > > Diffs > ----- > > src/cpu/kvm/vm.cc 704b0198f747b766b839c577614eb2924fd1dfee > src/mem/AbstractMemory.py 704b0198f747b766b839c577614eb2924fd1dfee > src/mem/abstract_mem.hh 704b0198f747b766b839c577614eb2924fd1dfee > src/mem/abstract_mem.cc 704b0198f747b766b839c577614eb2924fd1dfee > src/mem/physical.hh 704b0198f747b766b839c577614eb2924fd1dfee > src/mem/physical.cc 704b0198f747b766b839c577614eb2924fd1dfee > > Diff: http://reviews.gem5.org/r/3580/diff/ > > > Testing > ------- > > > Thanks, > > David Hashe > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
