> On Aug. 12, 2016, 8: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?
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.
- Andreas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3580/#review8602
-----------------------------------------------------------
On Aug. 5, 2016, 10: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, 10: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
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
