Alexander Graf <ag...@csgraf.de> writes:
> On 15.11.21 11:46, Peter Maydell wrote: >> On Sun, 14 Nov 2021 at 17:41, Alexander Graf <ag...@csgraf.de> wrote: >>> >>> >>>> Am 14.11.2021 um 18:20 schrieb Peter Maydell <peter.mayd...@linaro.org>: >>>> This is tricky, because we use the cpu->isar values to determine whether >>>> we should be emulating things. So this change means we now create an >>>> inconsistent CPU which in some ways claims to have EL3 (the ISAR ID >>>> bits say so) and in some ways does not (the ARM_FEATURE_EL3 flag is >>>> unset), and depending on which of the two "do we have EL3?" methods >>>> any bit of the TCG code is using will give different results... >>> Do you think it would be sufficient to go through all readers of >>> the isar bits and guard them behind an ARM_FEATURE_EL3 check in >>> addition? I'll be happy to do so then! :) >> That would be a big reverse-course on a design choice we made that >> the preference is to look at the ID registers and phase out the >> use of ARM_FEATURE bits where possible. > > > I'm open to alternatives. As it stands, we're lying to the guest > because we tell it "SMC is not available" but ask it to call SMC for > PSCI, which is bad too. Is testing the ISAR bits actually telling a guest that SMC exists or just the CPU is capable of handling it? I guess -kernel only is a weird case because otherwise if EL3 is available some sort of firmware has to have gotten the CPU into a state a kernel can boot. It doesn't imply that firmware knows how to do a PSCI call though - surely there is some firmware configuration/probing mechanism you need to rely on for that? -- Alex Bennée
