On 06/19/2017 01:59 PM, Florian Jakobsmeier wrote:
Hello Julien,
Hi Florian,
Please try to configure your e-mail client to quote using '>' rather
than tabulation. This is easier to follow the discussion.
thank you for your answer and sorry for the delay.
2017-06-14 14:26 GMT+02:00 Julien Grall <julien.gr...@arm.com
<mailto:julien.gr...@arm.com>>:
On 06/12/2017 10:34 AM, Florian Jakobsmeier wrote:
Dear all,
Hello Florian,
I don't have much experience with the debug registers, I have CCed
some folks who may have looked at it.
as part of my Bachelor's Thesis I'm trying to implement a
single-stepping functionality for Xen on ARMv7. My problem with
this is, that I'm not able to trigger a Hardware Breakpoint,
which is configured to use Instruction Address Mismatch and
route the exception to Xen.
You are looking at single-stepping for guest, right?
Yes I'm trying to implement guest single stepping.
I took the x86 single_step implementation as a reference. To
test my implementation I extended the given "xen-access" tool
test, in order to forward the SS request from xen-access.c to
./xen/arch/arm/monitor.c to the "arch_monitor_domctl_event"
function (just like the x86 implementation)
There, I set the necessary registers according to the ARM
Architectur Manual (ARM DDI 0406C-b). My basic idea is to
perform the following steps (in this order):
1) Configure the system to route debug exceptions to Hyp Mode
2) Initialize one breakpoint for Address Mismatching in
Non-Secure PL1/PL0
3) Define the "to be compared" address as "~0x3" (which is all
1s except Bit[1:0])
4) Set the MDBGen to 1 in order to enable Monitor Debug Mode
To check whether or not my values are set in the registers I
print every value before and after manipulation to ensure that
my values are adopted.
To access the registers I used the already defines Makros
(DBGBCR0), but for testing reasons I work with the general
definition (e.g. WRITE_SYSREG(#VALUE,p14,0,c0,c0,5) for DBGBCR0 ).
Preparation:
I ensured that the DBGen Signal is High, I checked the Debug
Version which is v7.1 (read from the DBGAUTHSTATUS). I also made
sure that the underlying system supports sufficient breakpoints.
These are the values I set in the different registers (in this
order again). Every bit that I don't mention is set to 0
- HDCR.{TDRA,TDOSA,TDA,TDE = 1}
which enables routing to Hyp. According to the ARM ARM setting
TDRA,TDOSA,TDA is required when setting TDE
- DBGBCR0.{BT=0b0100, SSC=0b01, PMC=0b11, E=0b1}= 0x404007
this should enable unlinked Address Musmatch, for Non-Secure PL0 >
- DBGBVR0.{IA = ~0x3}
which sets every bit to 1 (this address should never be reached
as it is mismatched)
- DBGDSCREXT.{MDBGen=1}
which enables Monitor Debug Mode
With the value set in HVBAR (hyp_traps_vector in
/xen/arch/arm/arm32/entry.S) the generated HypTrap (HypTrap
instead of PrefetchAbort because of the routing) should be
handled in do_trap_guest_sync. In this method the "hsr.ec
<http://hsr.ec> <http://hsr.ec>" Bits should indicate a
PrefetchAbort exception (hsr.ec <http://hsr.ec>
<http://hsr.ec>=0x20) whenever the Breakpoint triggers.
I added a simple if statement to print a string when such a
exception was thrown.
Unfortunately these prints are never generated, which indicates
that either I'm searching for the exception handling on the
wrong location or my breakpoints are not correctly configured.
To check if my configuration is wrong, I also tried the KDB
configuration for the DBGBCR (which is DBGBCR=0x4001E7 as far as
I understood). But this changed nothing in the behaviour.
As Hardware I tested my code with an Arndale as well as a Odroid
XU board (Exynos 5250).
It would be great if anyone, who has experience with the ARM
architecture, could help me in finding the missing information
that is required to successfully set up an address mismatch
breakpoint and succesfully route the associated exceptions to Xen.
I've looked at the spec and your description seem to match it. Where
do you configure the debug registers? Is it the vm_event handler or
when returning to the guest vCPU?
Ok thats good to hear. As mentioned, my approach is to extend the
xen_access test file. Which sets the registers in the Monitor.c in
/xen/xen/arch/arm (so from within the Hypervisor). Startet is this
routin from DOM0. So the execution starts in /tools/tests/xen-access and
gets forwarded to this function. I "trigger" this event by starting the
compiled xen-access.com <http://xen-access.com> file from within the Dom0
But I'm not quite sure whether this is what you wanted to know. >
Also, would you mind to share your code?
Here are the important parts: This is the extended Switch-Case in
monitor.c/arch_monitor_domctl_event()
+++ Github/xen/xen/arch/arm/monitor.c 2017-06-19 14:40:41.156356471 +0200
@@ -28,6 +28,7 @@
struct xen_domctl_monitor_op *mop)
{
struct arch_domain *ad = &d->arch;
bool_t requested_status = (XEN_DOMCTL_MONITOR_OP_ENABLE == mop->op);
switch ( mop->event )
@@ -45,6 +46,124 @@
break;
}
+ case XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP:
+ {
+ //Set Debug to Linked Addres
+ //See AARM C3.3.7 Linked comparisons for [...]
+
+ //Example on ARM ARM 2051
The DOMCTL hypercall will be issued by xen-access and executed on the
same CPU that did the hypercall. So what you are currently doing is
single-step the vCPU of the monitor domain.
However, what you want to is configure the CPU where the vCPU will run.
For a first implementation, a good candidate would be
leave_hypervisor_tail as this will be execute before returning to the
guest vCPU.
You would also ned some logic in enter_hypervisor_head to disable debug
monitor (maybe this could be done in ctxt_switch_from?).
However, I don't think this why you don't see debug event, as you would
just single step the current vCPU.
Looking at the code, I don't see any reset of the debug register
(similar to reset_ctrl_regs in linux/arch/arm/kernel/hw_breakpoint.c).
It might be good to go through what Linux does to set up breakpoint and
replicate to Xen.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
