How can the techniques gdbsx uses be adapted to a real-time monitoring of nested hypercalls? I handled the breakpoints in L1 dom0, instead of the L1 xen itself, just like dom0 handles the interrupt of domU. So it's not letting the guest dealing with themselves, right? To: quizy_jo...@outlook.com; t...@xen.org From: andrew.coop...@citrix.com Date: Fri, 18 Dec 2015 15:31:18 +0000 CC: george.dun...@eu.citrix.com; kevin.t...@intel.com; jun.nakaj...@intel.com; xen-devel@lists.xen.org Subject: Re: [Xen-devel] xen panics when setting int3 traps
On 17/12/15 01:35, quizyjones wrote: Sorry for the late reply, there is something wrong in network which makes the email not delivered successfully. The inject method is by using xc_map_foreign_range to map the address of the nested xen and memcpy the trap to the specific location. If there is a problem, it should be the xc_map_foreign_range function, can it map L1 xen's memory to dom0 of L0 xen? It might mapping the memory of nested dom0 instead of the nested xen, as the error says that the max physical address is 0xff000000 when I tried to operate on memory space of xen using xc_map_foreign_range. You cannot simply put breakpoints in the domain, as they will be handled by the domain itself. As you observe, Xen gets rightfully unhappy when it finds breapoints in its own virtual range. You need to follow the same actions as `gdbsx` (as an example) which registers itself as a debugger of the domain, and hooks breakpoints, rather than letting the guest deal with them in an unexpected manor. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel