Hello, I'm currently doing some research that involves examining the behavior of native code on paravirtualized Xen guests. gdbsx has proven somewhat limited for my use case, in large part due to the very limitations I describe below, so I have been writing my own application with some debugging capabilities to interface with the guests.
I have found, however, that quite a few major debugging features --- chiefly, breakpoints and single-step mode --- do not appear to be supported for PV guests. Looking through the source of Xen itself seems to confirm this [1]. It looks like the root cause of this is a lack of event monitoring support for PV guests, however, I have not been able to find much information online about whether or not there are other ways to do what I want. Is there any other way that I can use trap-based breakpoints or single step mode on PV guests (presumably without using the event monitoring API), or does Xen simply not support anything of the sort at the moment? If not, I might take a stab at adding support for it myself, but I'm not sure how complicated that would be. Thanks, Spencer [1] For instance: to enable single-step mode, the `XEN_DOMCTL_debug_op` syscall is used; its implementation `xen/arch/x86/domctl.c:978` bails out if the guest is not HVM, and otherwise calls what `hvm_debug_op()`, clearly an HVM-specific function. A similar trend appears to be the case for all the `xc_monitor_*` functions, e.g. `xc_monitor_software_breakpoint()`, which uses the `XC_DOMCTL_MONITOR_OP_ENABLE` domctl syscall. As best as I can tell, when that syscall is run, the VM's capabilities are checked at `xen/common/monitor.c:53`, and PV guests don't seem to have any monitoring capabilities.
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
