x86: Add support for m5ops through a memory mapped interface
Review Request #2024 - Created Sept. 20, 2013 and submitted
| Information | |
|---|---|
| Andreas Sandberg | |
| gem5 | |
| default | |
| Reviewers | |
| Default | |
Changeset 9885:f45348d9676b --------------------------- x86: Add support for m5ops through a memory mapped interface In order to support m5ops in virtualized environments, we need to use a memory mapped interface. This changeset adds support for that by reserving 0xFFFF0000-0xFFFFFFFF and mapping those to the generic IPR interface for m5ops. The mapping is done in the X86ISA::TLB::finalizePhysical() which means that it just works for all of the CPU models, including virtualized ones.
Ship It!
Posted (Oct. 22, 2014, 8:11 a.m.)
I ran across a small problem with this patch. The global pointer m5_mem is used inside of m5op_x86.S (if M5OP_ADDR is defined) and is declared inside of m5.c. This means that I can no longer link my ROI-annotated workload only to m5op_x86.o (because I need m5_mem). However, linking to m5.o to get at the m5_mem causes a symbol conflict on main(). One solution is simply to not use M5OP_ADDR (I'm not sure I need this feature at the moment). My workaround was to pull the m5_mem pointer and map_m5_mem() functions into its own m5_mem.o file and link to both m5op_x86.o and m5_mem.o I can post a patch if you think this is helpful.