Jim, I would highly recommend that you use the existing infrastructure. All you really need to do is write another couple PTLcall types and latch on to the current mechanism.
If you look at how this is done for PTLCALL_CHECKPOINT (in both ptl-qemu.cpp and ptlcall.h), you should start to see how the process is done. Basically, add as many case statements as you need to ptlcall_mmio_write in ptl-qemu.cpp and then add some ptlcall(...) stubs. Tyler > Hello, > > I'm interested in extending the ptlcalls mechanism so it works inside of > the Linux kernel. In particular, I'd like to be able to perform > ptlcall_log() operations and my own ptlcall_hybridsim() extension (see > bottom of this file: > https://github.com/jimstevens2001/marss.hybridsim/blob/marss.hybridsim/ptlsim/tools/ptlcalls.h) > based on decisions made by the Linux scheduler (e.g. when a context switch > occurs) and virtual memory subsystems (e.g. when a page is deallocated). > My first question is: has anyone attempted to make ptlcalls work in the > kernel before? > > I've studied the ptlcalls.h code and see that it uses the CPUID > instruction with a magic value to extract the physical address for MMIO > from rdx and rcx. However, the problem I see is that this code uses lots > of user level infrastructure such as opening /dev/mem with mmap() to > create a virtual address pointer to the page. > > Since I only have a very limited use case (e.g. I don't care about > checkpointing, core dumps, or other things ptlcalls are capable of), would > it be easier to just start from scratch and make a very limited version of > ptlcalls_kernel.h that can only call the ptlcalls I need? I was thinking I > could just hardcode the physical address since I won't have or need a > virtual pointer to it in the kernel. The ptlcall_do_mmio() function looks > pretty easy to port to kernel mode and I think that is all I'll really > need (beyond the wrapper functions to implement ptlcall_log and > ptlcall_hybridsim). > > Anyways, I'd appreciate any suggestions from the Binghamton guys about how > you'd go about doing this. > > Thanks, > > Jim Stevens > > > _______________________________________________ > 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
