Combining the answers to Andrew and Nikos. On Jul 17, 2023, at 1:53 AM, Nikos Nikoleris <nikos.nikoleris@xxxxxxx> wrote: > >>> >>> 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. I need to rehash the solution that you proposed for BSS (if there is anything special there). I had a different workaround for that issue, because IIRC I had some issues with the zeroing. I’ll give it another >> >> 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? >> I am afraid of turning on random bits on SCTLR. Arguably, the way that the non-efi test sets the default value of SCTLR (with no naming of the different bits) is not very friendly. I will have a look on the other bits of SCTLR and see if I can do something quick and simple, but I don’t want to refactor things in a way that might break things. > > Nadav, if you are running baremetal, it might be worth checking what EL > you're running in as well. If HW is implementing EL2, EFI will handover > in EL2. I don’t. I run the test on a different hypervisor. When I enabled the x86 tests to run on a different hypervisor years ago, there were many many test and real issues that required me to run KVM-unit-tests on bare metal - and therefore I fixed these tests to run on bare-metal as well. With ARM, excluding the BSS and the SCTLR issue, I didn’t encounter any additional test issues. So I don’t have the need or time to enable it to run on bare-metal… sorry.
