All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien@xen.org>
To: "Stefano Stabellini" <sstabellini@kernel.org>,
	"André Przywara" <andre.przywara@arm.com>
Cc: Bertrand Marquis <bertrand.marquis@arm.com>,
	xen-devel@lists.xenproject.org, Ian Jackson <iwj@xenproject.org>
Subject: Re: Smoke test failure on Arm (was Re: [PATCH v4 0/8] xen/arm: Emulate ID registers)
Date: Tue, 5 Jan 2021 19:15:56 +0000	[thread overview]
Message-ID: <7942af32-6bae-36c4-e1ee-dd3edc85097a@xen.org> (raw)
In-Reply-To: <alpine.DEB.2.21.2101051042230.4307@sstabellini-ThinkPad-T480s>

Hi Stefano,

On 05/01/2021 18:44, Stefano Stabellini wrote:
> On Tue, 5 Jan 2021, André Przywara wrote:
>> On 05/01/2021 16:06, Julien Grall wrote:
>>> (+ Ian and Andre)
>>>
>>> Hi Bertrand,
>>>
>>> On IRC, Ian pointed out that the smoke test was failing on Cubietruck.
>>> The only patches because the last success and the failure are your series.
>>>
>>> This seems to be a very early failure as there is no output from Xen [1].
>>>
>>> I originally thought the problem was because some of the ID registers
>>> (such as ID_PFR2) introduced in patch #2 doesn't exist in Armv7.
>>>
>>> But per B7.2.1 in ARM DDI 0406C.d, unallocated ID registers should be
>>> RAZ. So it would result to a crash. Andre confirmed that PFR2 can be
>>> accessed by writing a small baremetal code and booted on Cortex-A7 and
>>> Cortex-A20.
>>>
>>> So I am not entirely sure what's the problem. Andre kindly accepted to
>>> try to boot Xen on his board. Hopefully, this will give us a clue on the
>>> problem.
>>>
>>> If not, I will borrow a Cubietruck in OssTest and see if I can reproduce
>>> it and debug it.
>>
>>
>> So I just compiled master and staging and ran just that on an Allwinner
>> H3 (Cortex-A7 r0p5). Master boots fine (till it complains about the
>> missing Dom0, as expected). However staging indeed fails:
>>
>> (XEN) Xen version 4.15-unstable (andprz01@slackpad.lan)
>> (arm-slackware-linux-gnueabihf-gcc (GCC) 8.2.0) debug=y  Tue Jan  5
>> 16:09:40 GMT 2021
>> (XEN) Latest ChangeSet: Sun Nov 8 15:59:42 2020 +0100 git:c992efd06a
>> (XEN) build-id: 85d361b8565b90d4e0defe2beb2419e191fd76b4
>> (XEN) CPU0: Unexpected Trap: Undefined Instruction
>> (XEN) ----[ Xen-4.15-unstable  arm32  debug=y   Not tainted ]----
>> (XEN) CPU:    0
>> (XEN) PC:     0026b8c8 identify_cpu+0xc0/0xd4
>> (XEN) CPSR:   600001da MODE:Hypervisor
>> (XEN)      R0: 002acb20 R1: 00000000 R2: 00000000 R3: 11111111
>> (XEN)      R4: 002acb1c R5: 002acb20 R6: 4e000000 R7: 00000000
>> (XEN)      R8: 00000002 R9: 002d8200 R10:00008000 R11:002f7e6c R12:00000080
>> (XEN) HYP: SP: 002f7e68 LR: 002c419c
>> (XEN)
>> (XEN)   VTCR_EL2: 80002646
>> (XEN)  VTTBR_EL2: 00000018e628bb80
>> (XEN)
>> (XEN)  SCTLR_EL2: 30cd187f
>> (XEN)    HCR_EL2: 00000038
>> (XEN)  TTBR0_EL2: 000000004013a000
>> (XEN)
>> (XEN)    ESR_EL2: 00000000
>> (XEN)  HPFAR_EL2: 0003fff0
>> (XEN)      HDFAR: 9d110000
>> (XEN)      HIFAR: 0000a04a
>> (XEN)
>> (XEN) Xen stack trace from sp=002f7e68:
>> (XEN)    00000000 002f7f54 00008000 00000000 00002000 002a4584 00000000
>> 00000000
>> (XEN)    00000000 00008000 49ff5000 002d81f0 40000000 00000000 00002000
>> 00000001
>> (XEN)    00000000 50000000 49ffd000 00000000 50000000 00000000 00000000
>> 50000000
>> (XEN)    4c000000 00000000 4e000000 00000000 ffffffff ffffffff 50000000
>> 00000000
>> (XEN)    50000000 00000000 50000000 00000000 00000000 00000000 00000000
>> 00000000
>> (XEN)    00000000 00000003 00000000 00000000 ffffffff 00000040 ffffffff
>> 00000000
>> (XEN)    00000000 00000000 00000000 002a7000 40008050 0000001a 00000000
>> 49ff5000
>> (XEN)    40008000 3fe08000 00000004 0020006c 00000000 00000000 00000000
>> 00000000
>> (XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000
>> (XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000
>> (XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000
>> (XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000
>> (XEN)    00000000 00000000 00000000 00000000 00000000 00000000
>> (XEN) Xen call trace:
>> (XEN)    [<0026b8c8>] identify_cpu+0xc0/0xd4 (PC)
>> (XEN)    [<002c419c>] start_xen+0x778/0xe50 (LR)
>> (XEN)    [<002f7f54>] 002f7f54
>> (XEN)
>> (XEN)
>> (XEN) ****************************************
>> (XEN) Panic on CPU 0:
>> (XEN) CPU0: Unexpected Trap: Undefined Instruction
>> (XEN) ****************************************
>> (XEN)
>> (XEN) Reboot in five seconds...
>>
>>
>> The code in question:
>>    26b8c0:       eef63a10        vmrs    r3, mvfr1
>>    26b8c4:       e5803058        str     r3, [r0, #88]   ; 0x58
>>> 26b8c8:       eef53a10        vmrs    r3, mvfr2
>>    26b8cc:       e580305c        str     r3, [r0, #92]   ; 0x5c
>>    26b8d0:       e28bd000        add     sp, fp, #0
>>    26b8d4:       e49db004        pop     {fp}       ; (ldr fp, [sp], #4)
>>    26b8d8:       e12fff1e        bx      lr
>>
>> And indeed MVFR2 is not mentioned in the ARMv7 ARM, and in contrast to
>> the CP15 CPUID registers this is using the VMRS instruction, so it's not
>> protected by future-proof CPUID register scheme.
>>
>> Not sure what to do about this, maybe #ifdef'ing this register access
>> with arm64?
>> I guess this comes from the slightly too optimistic code-sharing between
>> arm32 and arm64?
> 
> Yes and #ifdef'ing is what we have been doing with the other registers.

There is a catch here. This register is accessible from AArch32 on all 
Armv8 HW. It is just not accessible on Armv7.

So hiding the MVFR2 behind #ifdef CONFIG_ARM_64 is technically not correct.

I know that we said that we don't officially support Xen on Arm32 on 
Armv8 HW (I can't find where it is written though). So we could argue 
that shadowing MVFR2 is not worth it.

I do use Armv8 HW to test 32-bit, so I would at least like to get Xen 
booting. In addition to that, Linux 32-bit doesn't access MVFR2 at the 
moment.

Therefore, a #ifdef may be acceptable for now. However, I would suggest 
to introduce name it MAY_BE_UNDEFINED (or similar) that will be used to 
avoid reading the system register on 32-bit.

For the 32-bit case, I would just hardcode the value based on the Arm 
(it looks like for Armv8-A there is only one valid value).

IOW, the hack would be self-contained in cpufeature.c.

Cheers,

-- 
Julien Grall


  parent reply	other threads:[~2021-01-05 19:16 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-10 11:56 [xen-unstable bisection] complete test-arm64-arm64-examine osstest service owner
2021-01-10 11:56 ` [xen-unstable test] 158303: regressions - FAIL osstest service owner
2020-12-17 15:38   ` [PATCH v4 0/8] xen/arm: Emulate ID registers Bertrand Marquis
2020-12-17 15:38     ` [PATCH v4 1/8] xen/arm: Use READ_SYSREG instead of 32/64 versions Bertrand Marquis
2020-12-17 23:17       ` Stefano Stabellini
2020-12-18 10:23         ` Bertrand Marquis
2020-12-17 15:38     ` [PATCH v4 2/8] xen/arm: Add ID registers and complete cpuinfo Bertrand Marquis
2020-12-17 23:22       ` Stefano Stabellini
2020-12-17 15:38     ` [PATCH v4 3/8] xen/arm: Add arm64 ID registers definitions Bertrand Marquis
2020-12-17 23:24       ` Stefano Stabellini
2020-12-17 15:38     ` [PATCH v4 4/8] xen/arm: create a cpuinfo structure for guest Bertrand Marquis
2020-12-17 23:26       ` Stefano Stabellini
2020-12-17 15:38     ` [PATCH v4 5/8] xen/arm: Add handler for ID registers on arm64 Bertrand Marquis
2020-12-17 23:31       ` Stefano Stabellini
2020-12-17 15:38     ` [PATCH v4 6/8] xen/arm: Add handler for cp15 ID registers Bertrand Marquis
2020-12-17 23:37       ` Stefano Stabellini
2020-12-18 10:14         ` Bertrand Marquis
2020-12-17 15:38     ` [PATCH v4 7/8] xen/arm: Add CP10 exception support to handle MVFR Bertrand Marquis
2020-12-17 23:40       ` Stefano Stabellini
2020-12-17 15:38     ` [PATCH v4 8/8] xen/arm: Activate TID3 in HCR_EL2 Bertrand Marquis
2020-12-17 23:42       ` Stefano Stabellini
2020-12-17 23:47     ` [PATCH v4 0/8] xen/arm: Emulate ID registers Stefano Stabellini
2020-12-18 10:12       ` Bertrand Marquis
2021-01-05 16:06     ` Smoke test failure on Arm (was Re: [PATCH v4 0/8] xen/arm: Emulate ID registers) Julien Grall
2021-01-05 16:28       ` André Przywara
2021-01-05 18:44         ` Stefano Stabellini
2021-01-05 19:05           ` [PATCH] xen/arm: do not read MVFR2 on arm32 Stefano Stabellini
2021-01-05 19:20             ` Julien Grall
2021-01-05 19:15           ` Julien Grall [this message]
2021-01-05 22:43             ` Smoke test failure on Arm (was Re: [PATCH v4 0/8] xen/arm: Emulate ID registers) Stefano Stabellini
2021-01-06 18:29               ` Julien Grall
2021-01-06 20:55                 ` Stefano Stabellini
2021-01-08 11:12                   ` Julien Grall
2021-01-11 11:19                     ` Smoke test failure on Arm (was Re: [PATCH v4 0/8] xen/arm: Emulate ID registers) [and 2 more messages] Ian Jackson
2021-01-11 11:25                       ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7942af32-6bae-36c4-e1ee-dd3edc85097a@xen.org \
    --to=julien@xen.org \
    --cc=andre.przywara@arm.com \
    --cc=bertrand.marquis@arm.com \
    --cc=iwj@xenproject.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.