On Tue, Jul 13, 2021 at 11:04:09AM +0200, Geert Uytterhoeven wrote: > Hi Sudeep, > > On Tue, Jul 13, 2021 at 10:56 AM Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > On Tue, Jul 13, 2021 at 10:30:36AM +0200, Geert Uytterhoeven wrote: [...] > > > And a possible use case: the RT CPU core may want to reset the AP GIC. > > > > I didn't want to add new bindings without details on the implementation > > to avoid possible issues with backward compatibility as this was not > > thought through completely and correctly before it was added. > > > > OK, now let us discuss your use-case: *RT CPU wants to reset AP GIC* > > > > 1. Will it just reset AP GIC or will it request the AP reset as a whole ? > > I am not sure if we can handle former, if you think otherwise what is > > the reset notification mechanism ? > > > > 2. Will that bypass secure world/PSCI ? Again more details on this would > > be helpful to visualise the entire use-case end-to-end better. > > > > By GIC reset, I am assuming it will be complete GIC reset including it's > > CPU interface. > > > > I don't think we can reset GIC without actual CPU reset. Even if we get > > some notification magically to the CPU that its GIC alone needs to be > > reset, it needs to safely higher exceptions to get its GIC CPU interface > > reprogrammed to correct (saved) values before OS can reprogram the NS > > world values. All these seems overall complicated and may be unnecessary. > > Probably both. Might make sense to reset on wake-up, after having disabled > clocks and powered down the AP CPU, AP GIC, ... > /me confused. If this is arm64 platform, then you have to use *PSCI* and I expect the reset to be done as part of CPU wake-up in PSCI firmware. > If that bypasses PSCI: well, if the unsecure software can do it, it > means the hardware is not secure. Or at least Linux has to be trusted. > No, if the system has PSCI, then you simply can't bypass that for GIC reset. Or at-least I am failing to understand the complete flow of that. -- Regards, Sudeep
