Kprobes reportedly works on Xen in a full-virtualization environment. I.e., if your kernel is running on top of qemu or VT hardware (e.g., AMD Pacifica or Intel Vanderpool), you can use the existing native Kprobes features. We also need to make kprobes work in a paravirtual ("Dom U") environment. Here's some background research from Will Cohen: ----- Talked with Stephen Tweedie about kprobes in Xen. Right now kprobes is disable in the Xen configuration because it doesn't work. Appearently there are things that build in Xen, but do not work. The current approach in Xen copies large chunks of code of specific architectures into Xen, then changes are made on the code. This leads to a maintence headaches. Having to copy patches over to Xen code and then modify them because of the additional Xen changes. This is one of the things that needs to changes before Xen is accepted in the mainline Linux kernel. There are patches being generated for the FC5 kernel by taking differences between the linus-2.6 (kernel.org) and merge-2.6 (xensource) kernels. These patches do not aways work because of the additional patches we have on FC5, e.g. VSDO builds in FC5 xen kernels but do not boot. Need a list of all the patches used to implement kprobes in the kernel. For this the related xen arch files could be generated and this could be used as a starting point. Otherwise it is going to be painful manual process to create the equivalent kprobes patch for Xen. However, once there is a patch, Stephen thought it was quite likely that the xensource people would be willing to accept it. One open question was whether Xen allows the text of the kernel to be modified. -Will ----- I replied: "Dan Stekloff posed this question on the Xen IRC, and the answer was yes, a guest kernel can modify its text." Regarding "Need a list of all the patches used to implement kprobes in the kernel," Will says: ----- This would be any kprobe related patch after the corresponding xen files was cloned (and mutated) from the original kernel file. As far as what redhat is currently using. Looking at http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/ Currently generates the xen kernels from: kernel-xen-2.6.12-1.13_FC5.src.rpm The base kernels are generated from: kernel-2.6.14-1.1735_FC5.src.rpm ----- I'm not very Xen-savvy, so feel free to correct anything in this background info.
For people who are interested in getting a Xen environment to work on getting kprobes to operate in Xen the following page is useful: http://fedoraproject.org/wiki/FedoraXenQuickstartFC5 -Will
This has been working for some time now... Was there additional validation you wanted, or can we close this?
(In reply to comment #2) > This has been working for some time now... Was there additional validation you > wanted, or can we close this? Can you attach a transcript of a successful session (with stap -vv ...)? Would this be an instrumentation of the dom0 or a domU kernel?
Created attachment 1302 [details] Simple transcript running on x86_64 2.6.17-1.2647.fc6xen (host) (In reply to comment #3) > Can you attach a transcript of a successful session (with stap -vv ...)? Sure, see below. I just ran a simple syscall.open test here, but I've run the testsuite before too with no problems (except that timer.profile probes never fire, a known issue separate from kprobes). > Would this be an instrumentation of the dom0 or a domU kernel? In Fedora, the two kernels are now merged. This transcript came from the host environment (dom0), but I've also run successfully in a paravirt guest (domU). This is on x86_64, but I know that Will Cohen has run on i686 as well. There are two bugs on the Red Hat bugzilla that were issues with Xen: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197220 This bug is closed, but it is still throwing an error (see transcript). Now at least the build continues anyway, but I think it's not really solved. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=200687 This bug hasn't been closed yet, but it's apparently been fixed. Anyway, the goal of this bug (kprobes on Xen) is complete.
(In reply to comment #4) > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197220 > This bug is closed, but it is still throwing an error (see transcript). Now > at least the build continues anyway, but I think it's not really solved. Self-correction: It's not really throwing an error, it's echoing the test that echoes an error if it detects a problem. At first glance this is misleading because it appears that the error actually occurred. The command performing the test should probably be cleaned up in this regard.
Xen has been tested to work fine with kprobes on i686 and x86_64, on both the host and paravirt guests. Let's assume for now that things are ok, and if other archs encounter problems later, we can open a more specific bug.