> On Jul 18, 2023, at 1:44 AM, Alexandru Elisei <alexandru.elisei@xxxxxxx> wrote: > > 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. I can give it a quick shot, but I do need to clarify something. Although I have rather deep knowledge of x86 architecture with over 20 years of experience, my experience with ARM is limited to 2 weeks. And I don’t even have an environment in which I can run KVM+ARM. So I am not inclined to revamp code that was actually just added to kvm-unit-tests. I will attempt to refactor the code to solve both the BSS and SCTLR issues in EFI under these limitations.
