[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xen panics when setting int3 traps

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_jones@xxxxxxxxxxx; tim@xxxxxxx
From: andrew.cooper3@xxxxxxxxxx
Date: Fri, 18 Dec 2015 15:31:18 +0000
CC: george.dunlap@xxxxxxxxxxxxx; kevin.tian@xxxxxxxxx; jun.nakajima@xxxxxxxxx; xen-devel@xxxxxxxxxxxxx
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.


_______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.