Pete, As far as translating virtual to physical addresses goes, MARSS provides a std::map (hvirt_gphys_maps) that you can use to perform the translation. You can also study qemu's softmmu code and use their virtualized TLB to do the same (see qemu/target-i386/translate.c).
As far as copying the actual memory, study both Context::copy_from_vm and qemu's softmmu code. qemu provides a plethora of "templated" functions via the softmmu_template.h header to load and store different sized parameters. MARSS uses these functions (cpu_ldub_kernel, cpu_ldq_kernel, etc.) extensively to access qemu's memory space. If you believe that any of the features that you have developed would be useful to the majority of the MARSS community (memory tracing, etc.) please feel free to send patches upstream so we can apply them to the repository. Best, Tyler > Team MARSS: > > I need my memory trace to print the memory content, i.e. in addition to > op-type, physical address, and timestamp. How can I translate from the > MARSS physical address to an address that will allow for me to grab the > content from the qemu memory model? i.e. how do I grab the content based > on MARSS physical address? > > For some additional context, I have made some progress with adding memory > tracing capability, and several obstacles have been toppled, namely: > ... running a multicore config w/ 3 level cache hierarchy > ... running with bidirectional network connectivity > ... and others... > > Thank you, > Pete Stevenson > _______________________________________________ > http://www.marss86.org > Marss86-Devel mailing list > [email protected] > https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel > _______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
