Re: [Xen-devel] [PATCH] arm/vm_event: get/set registers

[Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

On Thu, Jul 28, 2016 at 4:03 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
>
>
> On 28/07/2016 22:33, Tamas K Lengyel wrote:
>>
>> On Jul 28, 2016 15:25, "Julien Grall" <julien.grall@xxxxxxx
>> <mailto:julien.grall@xxxxxxx>> wrote:
>>>
>>>
>>>
>>>
>>> On 28/07/2016 22:05, Tamas K Lengyel wrote:
>>>>
>>>>
>>>> On Thu, Jul 28, 2016 at 3:01 PM, Julien Grall <julien.grall@xxxxxxx
>>
>> <mailto:julien.grall@xxxxxxx>> wrote:
>>>>
>>>> That's not how we do it with vm_event. Even on x86 we only selectively
>>>> set registers using the VM_EVENT_FLAG_SET_REGISTERS flag (albeit it
>>>> not being documented in the header). As for "not exposing them" it's a
>>>> waste to declare separate structures for getting and setting. I'll
>>>> change my mind about that if Razvan is on the side that we should
>>>> start doing that, but I don't think that's the case at the moment.
>>>
>>>
>>>
>>> Is there any rationale to only set a subset of the information you
>>
>> retrieved?
>>>
>>>
>>
>> I just did a testrun with setting every register through this method to
>> 0 other then pc and it resulted in hypervisor crash. Not sure if it's
>> just my setup or not though so I'm still poking at it. However, I don't
>> really see a usecase where setting ttbr regs to be required either via
>> the fast method so it simply may not worth digging into it more at this
>> time.
>
>
> To confirm, do you mean setting CPSR, TTBR0_EL1, TTBR1_EL1 to 0?
>
> TTBR*_EL1 are safe to set to any values (they are directly accessible by the
> guest anyway). However this is not the case of CPSR. From my understanding
> of the ARM ARM (B1-1150 in ARM DDI 0406C.b) is writing 0 to M[4:0] will lead
> to an unpredictable behavior (that could cause an hypervisor trap).
>
> Can you copy/paste the hypervisor crash log?
>

OK, the issue I had was that right now mem_access on ARM doesn't send
the registers (yet) as it needs my monitor_traps work from the other
patch so I kept setting all registers to 0. Rebasing on top of my
other patch now I was able to verify that indeed only setting cpsr to
arbitrary values (like 0) can cause hypervisor crash as follows:

(XEN) CPU1: Unexpected Trap: Prefetch Abort
(XEN) ----[ Xen-4.8-unstable  arm32  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) PC:     c09195f4
(XEN) CPSR:   0000001a MODE:Hypervisor
(XEN)      R0: 600f0013 R1: 390038ff R2: c0dd4540 R3: 38ff38ff
(XEN)      R4: 00000000 R5: c0dd4240 R6: c7fb0a64 R7: 00000001
(XEN)      R8: c7eaaf60 R9: c0dd4240 R10:c7eaaf58 R11:00000000 R12:00000000
(XEN) USR: SP: beb4e20c LR: 7f5883ed
(XEN) SVC: SP: c277ddc0 LR: c02caf58 SPSR:800f0030
(XEN) ABT: SP: c0dd9a4c LR: c02147c0 SPSR:80070193
(XEN) UND: SP: c0dd9a58 LR: c0214880 SPSR:20060093
(XEN) IRQ: SP: c0dd9a40 LR: c0214800 SPSR:600f0193
(XEN) FIQ: SP: c0dd9a64 LR: c0dd9a64 SPSR:00000000
(XEN) FIQ: R8: 00000000 R9: 00000000 R10:00000000 R11:00000000 R12:00000000
(XEN)
(XEN)      SCTLR: 10c5387d
(XEN)        TCR: 00000000
(XEN)      TTBR0: 00000000426b806a
(XEN)      TTBR1: 000000004020406a
(XEN)       IFAR: b6e75480, IFSR: 00000007
(XEN)       DFAR: 7f5ab024, DFSR: 00000017
(XEN)
(XEN)   VTCR_EL2: 80003558
(XEN)  VTTBR_EL2: 00020000bfa86000
(XEN)
(XEN)  SCTLR_EL2: 30cd187f
(XEN)    HCR_EL2: 000000000038663f
(XEN)  TTBR0_EL2: 00000000bdfea000
(XEN)
(XEN)    ESR_EL2: 84000006
(XEN)  HPFAR_EL2: 000000000001c810
(XEN)      HDFAR: e0800f00
(XEN)      HIFAR: c09195f4
(XEN)
(XEN) Xen BUG at traps.c:946
(XEN) ----[ Xen-4.8-unstable  arm32  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) PC:     0025ee4c traps.c#show_guest_stack+0xcc/0x274
(XEN) CPSR:   8000011a MODE:Hypervisor
(XEN)      R0: 40064000 R1: 43fcff58 R2: 43ce9d00 R3: 0000000a
(XEN)      R4: 43fcff9c R5: 40064000 R6: 00282608 R7: 43fcff58
(XEN)      R8: c7eaaf60 R9: c0dd4240 R10:c7eaaf58 R11:43fcff0c R12:00000000
(XEN) HYP: SP: 43fcfedc LR: 0025f69c
(XEN)
(XEN)   VTCR_EL2: 80003558
(XEN)  VTTBR_EL2: 00020000bfa86000
(XEN)
(XEN)  SCTLR_EL2: 30cd187f
(XEN)    HCR_EL2: 000000000038663f
(XEN)  TTBR0_EL2: 00000000bdfea000
(XEN)
(XEN)    ESR_EL2: 00000000
(XEN)  HPFAR_EL2: 000000000001c810
(XEN)      HDFAR: e0800f00
(XEN)      HIFAR: c09195f4
(XEN)
(XEN) Xen stack trace from sp=43fcfedc:
(XEN)    00282608 43fcff58 c7eaaf60 c0dd4240 43fcff9c 00281a74 00282608 43fcff58
(XEN)    c7eaaf60 c0dd4240 c7eaaf58 43fcff2c 0025f69c 43fcff58 00281a74 00282608
(XEN)    43fcff58 c7eaaf60 c0dd4240 43fcff3c 0025f848 0030b614 00281a74 43fcff4c
(XEN)    0025f94c 00000000 00000001 43fcff54 002650f0 43fcff58 00264e90 600f0013
(XEN)    390038ff c0dd4540 38ff38ff 00000000 c0dd4240 c7fb0a64 00000001 c7eaaf60
(XEN)    c0dd4240 c7eaaf58 00000000 00000000 43fcff9c 7f5883ed c09195f4 0000001a
(XEN)    00000007 beb4e20c c0dd9a40 c0214800 c277ddc0 c02caf58 c0dd9a4c c02147c0
(XEN)    c0dd9a58 c0214880 00000000 00000000 00000000 00000000 00000000 c0dd9a64
(XEN)    c0dd9a64 800f0030 80070193 20060093 600f0193 00000000 00000000 00000000
(XEN)    00000000
(XEN) Xen call trace:
(XEN)    [<0025ee4c>] traps.c#show_guest_stack+0xcc/0x274 (PC)
(XEN)    [<0025f69c>] show_stack+0x78/0x204 (LR)
(XEN)    [<0025f69c>] show_stack+0x78/0x204
(XEN)    [<0025f848>] show_execution_state+0x20/0x34
(XEN)    [<0025f94c>] do_unexpected_trap+0x48/0x5c
(XEN)    [<002650f0>] do_trap_data_abort+0/0x1c
(XEN)    [<00264e90>] entry.o#return_from_trap+0/0x4
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 1:
(XEN) Xen BUG at traps.c:946
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...

Setting ttb/cr/r0/r1 is fine however as it only causes an in-guest
kernel crash. So we still need to selectively set registers and as at
this point only PC makes sense we will start with just that.

Tamas

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