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
