Hi Conor, On Sat, Jun 22, 2024 at 8:01 PM Conor Dooley <conor@xxxxxxxxxx> wrote: > > On Fri, Jun 21, 2024 at 05:08:01PM +0200, Andrew Jones wrote: > > On Fri, Jun 21, 2024 at 03:58:18PM GMT, Conor Dooley wrote: > > > On Fri, Jun 21, 2024 at 04:52:09PM +0200, Andrew Jones wrote: > > > > On Fri, Jun 21, 2024 at 03:04:47PM GMT, Conor Dooley wrote: > > > > > On Fri, Jun 21, 2024 at 03:15:10PM +0200, Andrew Jones wrote: > > > > > > On Fri, Jun 21, 2024 at 02:42:15PM GMT, Alexandre Ghiti wrote: > > > > > > > > > I understand the concern; old SBI implementations will leave svadu in the > > > > > > DT but not actually enable it. Then, since svade may not be in the DT if > > > > > > the platform doesn't support it or it was left out on purpose, Linux will > > > > > > only see svadu and get unexpected exceptions. This is something we could > > > > > > force easily with QEMU and an SBI implementation which doesn't do anything > > > > > > for svadu. I hope vendors of real platforms, which typically provide their > > > > > > own firmware and DTs, would get this right, though, especially since Linux > > > > > > should fail fast in their testing when they get it wrong. > > > > > > > > > > I'll admit, I wasn't really thinking here about something like QEMU that > > > > > puts extensions into the dtb before their exact meanings are decided > > > > > upon. I almost only ever think about "real" systems, and in those cases > > > > > I would expect that if you can update the representation of the hardware > > > > > provided to (or by the firmware to Linux) with new properties, then updating > > > > > the firmware itself should be possible. > > > > > > > > > > Does QEMU have the this exact problem at the moment? I know it puts > > > > > Svadu in the max cpu, but does it enable the behaviour by default, even > > > > > without the SBI implementation asking for it? > > > > > > > > Yes, because QEMU has done hardware A/D updating since it first started > > > > supporting riscv, which means it did svadu when neither svadu nor svade > > > > were in the DT. The "fix" for that was to ensure we have svadu and !svade > > > > by default, which means we've perfectly realized Alexandre's concern... > > > > We should be able to change the named cpu types that don't support svadu > > > > to only have svade in their DTs, since that would actually be fixing those > > > > cpu types, but we'll need to discuss how to proceed with the generic cpu > > > > types like 'max'. > > > > > > Correct me please, since I think I am misunderstanding: At the moment > > > QEMU does A/D updating whether or not the SBI implantation asks for it, > > > with the max CPU. The SBI implementation doesn't understand Svadu and > > > won't strip it. The kernel will get a DT with Svadu in it, but Svadu will > > > be enabled, so it is not a problem. > > > > Oh, of course you're right! I managed to reverse things some odd number of > > times (more than once!) in my head and ended up backwards... > > I mean, I've been really confused about this whole thing the entire > time, so ye.. > > Speaking of QEMU, what happens if I try to turn on svade and svadu in > QEMU? It looks like there's some handling of it that does things > conditionally based !svade && svade, but I couldn't tell if it would do > what we are describing in this thread. When both Svadu and Svade are specified in QEMU, the reset value of menvcfg.ADUE is 0: env->menvcfg = (cpu->cfg.ext_svpbmt ? MENVCFG_PBMTE : 0) | (!cpu->cfg.ext_svade && cpu->cfg.ext_svadu ? MENVCFG_ADUE : 0); The runtime behavior depends on menvcfg.ADUE: bool svade = riscv_cpu_cfg(env)->ext_svade; bool svadu = riscv_cpu_cfg(env)->ext_svadu; bool adue = svadu ? env->menvcfg & MENVCFG_ADUE : !svade; Regardless of whether OpenSBI supports the Svadu enablement, Supervisor can assume that QEMU uses Svade when it doesn't explicitly turn on Svadu. Regards, Yong-Xuan