Whoops, missed the 'from the kernel' part. Assuming you're talking about the guest kernel...
The easiest way would be to write directly to the PTLcall MMIO address ( 0x00000008fffff000ULL), so qemu catches it and makes the PTLcall accordingly. Since you're in the kernel, you should just be able to write directly to physical memory addresses. The only reason we have all the userspace infrastructure is to map that MMIO address into our virtual address space. Tyler > 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 > _______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
