> From: Alexander Graf <ag...@suse.de> > Date: Tue, 12 Jun 2018 22:32:38 +0200 > > On 12.06.18 22:17, Mark Kettenis wrote: > >> From: Alexander Graf <ag...@suse.de> > >> Date: Tue, 12 Jun 2018 20:46:02 +0200 > >> > >> On 12.06.18 19:27, Mark Kettenis wrote: > >>> The current code that switches into HYP mode doesn't bother to set > >>> up a stack for HYP mode. This doesn't work for EFI applications > >>> as they expect a usable stack. Fix this by saving the stack > >>> pointer before switching and use it to set SP_hyp from monitor. > >>> This restores the stack pointer when we drop into HYP mode. > >>> > >>> Signed-off-by: Mark Kettenis <kette...@openbsd.org> > >> > >> Can we be sure that the stack in MON is usable from HYP? > > > > I think so. It is the stack that U-Boot sets up for itself in normal > > memory. As far as I can tell arm64 re-uses this stack when dropping > > down into EL2 as well. > > Well, the question is whether it's secure or non-secure memory. Usually > the DRAM controller can be configured to have a window of RAM only > available to secure and I'd certainly hope that at least the U-Boot > parts that are preserved in EL3 live in such a secured area :)
The U-Boot PSCI implementation ends up in a special memory region and uses a separate stack in that same region. Whether that memory region is marked as secure in hardware depends on board-specific code. On the i.MX7D board I'm playing with it ends up in on on-chip RAM but I'm not sure the current U-Boot code actually marks that region as secure. In principle the PSCI code is all that is preserved for MON/EL3. My diffs really don't change how that works. The code is already there and it already works (I assume) when booting Linux kernels in non-secure mode the traditional (non-EFI) way. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
