Hi, On Mon, Jul 17, 2023 at 05:05:06PM +0000, Nadav Amit wrote: > 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 What do you mean by turning on random bits on SCTLR? All the functional bits are documented in the architecture. Same goes for RES1 (it's in the Glossary). > the non-efi test sets the default value of SCTLR (with no naming of the > different bits) is not very friendly. That's because as the architecture gets updated, what used to be a RES1 bit becomes a functional bit. The only sane way to handle this is to disable all the features you don't support, **and** set all the RES1 bits (and clear RES0 bits), to disable any newly introduced features you don't know about yet which were left enabled by software running at a higher privilege level. You can send a patch if you want to give a name to the bits which have become functional since SCTLR_EL1_RES1 was introduced. Thanks, Alex > > 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. >
