Re: psci function id register on arm64

[Mark Kettenis]

> Date: Sun, 28 Jan 2018 14:35:52 +1100
> From: Jonathan Gray 
> 
> semarie reported problems with running arm64 on qemu which turned
> out to be triggered by the psci version call.
> 
> [ using 979488 bytes of bsd ELF symbol table ]
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2018 OpenBSD. All rights reserved.  https://www.OpenBSD.org
> 
> OpenBSD 6.2-current (GENERIC) #160: Wed Jan 24 18:26:59 MST 2018
> dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC
> real mem  = 2105647104 (2008MB)
> avail mem = 2017124352 (1923MB)
> mainbus0 at root: unknown model
> cpu0 at mainbus0: ARM Cortex-A57 r1p0
> efi0 at mainbus0: UEFI 2.0.5
> efi0: Das U-Boot rev 0x0
> psci0 at mainbus0Stopped at  psci_attach+0xf4:
> ddb> tr
> hvc_call() at psci_attach+0xf0
> psci_attach() at mainbus_attach_node+0x244
> mainbus_attach_node() at mainbus_attach+0x1ec
> mainbus_attach() at config_attach+0x214
> config_attach() at config_rootfound+0xc0
> config_rootfound() at cpu_configure+0x34
> cpu_configure() at main+0x348
> main() at $x.2+0x70
> ddb> sh reg
> x00x8400
> x1 0
> x2 0
> x3 0
> x40xff80008bf258initstack+0x4a68
> x50x1323
> x60x861e4d1cb67f8248
> x70x861e4d1cb67f8248
> x80xff8000571978hvc_call
> x90x8408
> x10   0x8409
> x110
> x120
> x130
> x14   0xff80073ad744_end+0x6a5ac0c
> x15   0xff8000671f20ap_bits_user
> x16   0xb64c1a07
> x17   0xef56e85d
> x18   0xff80008bf200initstack+0x4a10
> x19   0xff80073ac200_end+0x6a596c8
> x20   0xff80008bf310initstack+0x4b20
> x21   0xff800080$d.5
> x220
> x23   0xff80073ac224_end+0x6a596ec
> x24   0xff8000813388psci_cd
> x25   0xff8000813360psci_ca
> x26   0xff800095gf_log+0x1bc
> x27   0x4085f000
> x28   0x4020
> x29   0xff80008bf2b0initstack+0x4ac0
> x300
> sp0xff80008bf200initstack+0x4a10
> spsr  0x63c5
> elr   0xff8000571978hvc_call
> lr0xff8000254d08psci_attach+0xf4
> psci_attach+0xf4:
> 
> Though it seems other calls had trouble before that, likely since the
> psci changes made in december.
> 
> Attempting to power down...
> Stopped at  boot+0xd4:
> ddb> tr
> hvc_call() at boot+0xd0
> boot() at sys_reboot+0x2c
> reboot() at svc_handler+0x1bc
> svc_handler() at do_el0_sync+0xbc
> do_el0_sync() at handle_el0_sync+0x68
> handle_el0_sync() at 0x4ca7b07a4
> --- trap ---
> ddb> sh reg
> x00x8408
> x1 0
> x2 0
> x3 0
> x40xff8000277918hvc_call
> x5 0
> x60x33781a588ce87b4c
> x70x33781a588ce87b4c
> x80xff80072f7200_end+0x69a49d8
> x90x25bf00aba3ce1b98
> x10  0x16707157c
> x11 0x64
> x120x1dcd662__ALIGN_SIZE+0x1bcd662
> x13  0xc
> x14   0xff8007235184_end+0x68e295c
> x150
> x160
> x17 0x10
> x18   0xff8018b00d90
> x19   0x1008
> x20   0xff8000805000nv2tov_type+0x8
> x21 0x37
> x22 0x37
> x23   0xff8018b00f00
> x24   0xff800080$d.5
> x25   0xff8000856360sysent
> x26 0x37
> x27   0xff80008566d2sysent+0x372
> x28  0x1
> x29   0xff8018b00da0
> x30   0x4f49c4fa
> sp0xff8018b00d90
> spsr  0x63c5
> elr   0xff8000277918hvc_call
> lr0xff80002433f0boot+0xd4
> boot+0xd4:
> 
> qemu-system-aarch64 doesn't recognise the psci call when the high 32 bits
> of x0 are not zero.  The PSCI implemented by the ATF in the
> overdrive 1000 only looks at the low 32 bits.  And all the function ids
> we use set bit 31.  

psci function id register on arm64

[Jonathan Gray]

semarie reported problems with running arm64 on qemu which turned
out to be triggered by the psci version call.

[ using 979488 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2018 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.2-current (GENERIC) #160: Wed Jan 24 18:26:59 MST 2018
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC
real mem  = 2105647104 (2008MB)
avail mem = 2017124352 (1923MB)
mainbus0 at root: unknown model
cpu0 at mainbus0: ARM Cortex-A57 r1p0
efi0 at mainbus0: UEFI 2.0.5
efi0: Das U-Boot rev 0x0
psci0 at mainbus0Stopped at  psci_attach+0xf4:
ddb> tr
hvc_call() at psci_attach+0xf0
psci_attach() at mainbus_attach_node+0x244
mainbus_attach_node() at mainbus_attach+0x1ec
mainbus_attach() at config_attach+0x214
config_attach() at config_rootfound+0xc0
config_rootfound() at cpu_configure+0x34
cpu_configure() at main+0x348
main() at $x.2+0x70
ddb> sh reg
x00x8400
x1 0
x2 0
x3 0
x40xff80008bf258initstack+0x4a68
x50x1323
x60x861e4d1cb67f8248
x70x861e4d1cb67f8248
x80xff8000571978hvc_call
x90x8408
x10   0x8409
x110
x120
x130
x14   0xff80073ad744_end+0x6a5ac0c
x15   0xff8000671f20ap_bits_user
x16   0xb64c1a07
x17   0xef56e85d
x18   0xff80008bf200initstack+0x4a10
x19   0xff80073ac200_end+0x6a596c8
x20   0xff80008bf310initstack+0x4b20
x21   0xff800080$d.5
x220
x23   0xff80073ac224_end+0x6a596ec
x24   0xff8000813388psci_cd
x25   0xff8000813360psci_ca
x26   0xff800095gf_log+0x1bc
x27   0x4085f000
x28   0x4020
x29   0xff80008bf2b0initstack+0x4ac0
x300
sp0xff80008bf200initstack+0x4a10
spsr  0x63c5
elr   0xff8000571978hvc_call
lr0xff8000254d08psci_attach+0xf4
psci_attach+0xf4:

Though it seems other calls had trouble before that, likely since the
psci changes made in december.

Attempting to power down...
Stopped at  boot+0xd4:
ddb> tr
hvc_call() at boot+0xd0
boot() at sys_reboot+0x2c
reboot() at svc_handler+0x1bc
svc_handler() at do_el0_sync+0xbc
do_el0_sync() at handle_el0_sync+0x68
handle_el0_sync() at 0x4ca7b07a4
--- trap ---
ddb> sh reg
x00x8408
x1 0
x2 0
x3 0
x40xff8000277918hvc_call
x5 0
x60x33781a588ce87b4c
x70x33781a588ce87b4c
x80xff80072f7200_end+0x69a49d8
x90x25bf00aba3ce1b98
x10  0x16707157c
x11 0x64
x120x1dcd662__ALIGN_SIZE+0x1bcd662
x13  0xc
x14   0xff8007235184_end+0x68e295c
x150
x160
x17 0x10
x18   0xff8018b00d90
x19   0x1008
x20   0xff8000805000nv2tov_type+0x8
x21 0x37
x22 0x37
x23   0xff8018b00f00
x24   0xff800080$d.5
x25   0xff8000856360sysent
x26 0x37
x27   0xff80008566d2sysent+0x372
x28  0x1
x29   0xff8018b00da0
x30   0x4f49c4fa
sp0xff8018b00d90
spsr  0x63c5
elr   0xff8000277918hvc_call
lr0xff80002433f0boot+0xd4
boot+0xd4:

qemu-system-aarch64 doesn't recognise the psci call when the high 32 bits
of x0 are not zero.  The PSCI implemented by the ATF in the
overdrive 1000 only looks at the low 32 bits.  And all the function ids
we use set bit 31.  Bit 30 is used to indicate smc64/hvc64 calling
convention.  The smc calling convention specification states that up to
six registers are used, but nothing we call needs that many yet.

Tested on overdrive 1000, and 32/64 bit qemu -M virt.

Index: psci.c