On Mon, Jul 17, 2023 at 08:50:30AM +0200, Andrew Jones wrote: > On Fri, Jul 14, 2023 at 06:42:25PM +0000, Nadav Amit wrote: > > > > > > > On Jul 14, 2023, at 4:29 AM, Shaoqin Huang <shahuang@xxxxxxxxxx> wrote: > > > > > > !! External Email > > > > > > Hi, > > > > > > On 7/14/23 18:31, Alexandru Elisei wrote: > > >> Hi, > > >> > > >> On Sat, Jun 17, 2023 at 01:31:37AM +0000, Nadav Amit wrote: > > >>> From: Nadav Amit <namit@xxxxxxxxxx> > > >>> > > >>> Do not assume PAN is not supported or that sctlr_el1.SPAN is already set. > > >> > > >> In arm/cstart64.S > > >> > > >> .globl start > > >> start: > > >> /* get our base address */ > > >> [..] > > >> > > >> 1: > > >> /* zero BSS */ > > >> [..] > > >> > > >> /* zero and set up stack */ > > >> [..] > > >> > > >> /* set SCTLR_EL1 to a known value */ > > >> ldr x4, =INIT_SCTLR_EL1_MMU_OFF > > >> [..] > > >> > > >> /* set up exception handling */ > > >> bl exceptions_init > > >> [..] > > >> > > >> Where in lib/arm64/asm/sysreg.h: > > >> > > >> #define SCTLR_EL1_RES1 (_BITUL(7) | _BITUL(8) | _BITUL(11) | _BITUL(20) | \ > > >> _BITUL(22) | _BITUL(23) | _BITUL(28) | _BITUL(29)) > > >> #define INIT_SCTLR_EL1_MMU_OFF \ > > >> SCTLR_EL1_RES1 > > >> > > >> Look like bit 23 (SPAN) should be set. > > >> > > >> How are you seeing SCTLR_EL1.SPAN unset? > > > > > > Yeah. the sctlr_el1.SPAN has always been set by the above flow. So Nadav > > > you can describe what you encounter with more details. Like which tests > > > crash you encounter, and how to reproduce it. > > > > I am using Nikos’s work to run the test using EFI, not from QEMU. > > > > So the code that you mentioned - which is supposed to initialize SCTLR - > > is not executed (and actually not part of the EFI image). > > > > Note that using EFI, the entry point is _start [1], and not “start”. > > > > That is also the reason lack of BSS zeroing also caused me issues with the > > EFI setup, which I reported before. > > Nadav, > > Would you mind reposting this along with the BSS zeroing patch, the > way I proposed we do that, and anything else you've discovered when > trying to use the EFI unit tests without QEMU? We'll call that our > first non-QEMU EFI support series, since the first EFI series was > only targeting QEMU. Oh, and I meant to mention that, when reposting this patch, maybe we can consider managing sctlr in a similar way to the non-efi start path? Thanks, drew
