On Mon, Jun 3, 2024 at 4:59 PM Alexandre Ghiti <alex@xxxxxxxx> wrote: > > On 30/05/2024 11:24, Andrew Jones wrote: > > On Thu, May 30, 2024 at 11:01:20AM GMT, Alexandre Ghiti wrote: > >> Hi Andrew, > >> > >> On 30/05/2024 10:47, Andrew Jones wrote: > >>> On Thu, May 30, 2024 at 10:19:12AM GMT, Alexandre Ghiti wrote: > >>>> Hi Yong-Xuan, > >>>> > >>>> On 27/05/2024 18:25, Andrew Jones wrote: > >>>>> On Fri, May 24, 2024 at 06:33:01PM GMT, Yong-Xuan Wang wrote: > >>>>>> Svadu is a RISC-V extension for hardware updating of PTE A/D bits. > >>>>>> > >>>>>> In this patch we detect Svadu extension support from DTB and enable it > >>>>>> with SBI FWFT extension. Also we add arch_has_hw_pte_young() to enable > >>>>>> optimization in MGLRU and __wp_page_copy_user() if Svadu extension is > >>>>>> available. > >>>> So we talked about this yesterday during the linux-riscv patchwork meeting. > >>>> We came to the conclusion that we should not wait for the SBI FWFT extension > >>>> to enable Svadu but instead, it should be enabled by default by openSBI if > >>>> the extension is present in the device tree. This is because we did not find > >>>> any backward compatibility issues, meaning that enabling Svadu should not > >>>> break any S-mode software. > >>> Unfortunately I joined yesterday's patchwork call late and missed this > >>> discussion. I'm still not sure how we avoid concerns with S-mode software > >>> expecting exceptions by purposely not setting A/D bits, but then not > >>> getting those exceptions. > >> > >> Most other architectures implement hardware A/D updates, so I don't see > >> what's specific in riscv. In addition, if an OS really needs the exceptions, > >> it can always play with the page table permissions to achieve such > >> behaviour. > > Hmm, yeah we're probably pretty safe since sorting this out is just one of > > many things an OS will have to learn to manage when getting ported. Also, > > handling both svade and svadu at boot is trivial since the OS simply needs > > to set the A/D bits when creating the PTEs or have exception handlers > > which do nothing but set the bits ready just in case. > > > >> > >>>> This is what you did in your previous versions of > >>>> this patchset so the changes should be easy. This behaviour must be added to > >>>> the dtbinding description of the Svadu extension. > >>>> > >>>> Another thing that we discussed yesterday. There exist 2 schemes to manage > >>>> the A/D bits updates, Svade and Svadu. If a platform supports both > >>>> extensions and both are present in the device tree, it is M-mode firmware's > >>>> responsibility to provide a "sane" device tree to the S-mode software, > >>>> meaning the device tree can not contain both extensions. And because on such > >>>> platforms, Svadu is more performant than Svade, Svadu should be enabled by > >>>> the M-mode firmware and only Svadu should be present in the device tree. > >>> I'm not sure firmware will be able to choose svadu when it's available. > >>> For example, platforms which want to conform to the upcoming "Server > >>> Platform" specification must also conform to the RVA23 profile, which > >>> mandates Svade and lists Svadu as an optional extension. This implies to > >>> me that S-mode should be boot with both svade and svadu in the DT and with > >>> svade being the active one. Then, S-mode can choose to request switching > >>> to svadu with FWFT. > >> > >> The problem is that FWFT is not there and won't be there for ~1y (according > >> to Anup). So in the meantime, we prevent all uarchs that support Svadu to > >> take advantage of this. > > I think we should have documented behaviors for all four possibilities > > > > 1. Neither svade nor svadu in DT -- current behavior > > 2. Only svade in DT -- current behavior > > 3. Only svadu in DT -- expect hardware A/D updating > > 4. Both svade and svadu in DT -- current behavior, but, if we have FWFT, > > then use it to switch to svadu. If we don't have FWFT, then, oh well... > > > > Platforms/firmwares that aren't concerned with the profiles can choose (3) > > and Linux is fine. Those that do want to conform to the profile will > > choose (4) but Linux won't get the benefit of svadu until it also gets > > FWFT. > > > I think this solution pleases everyone so I'd say we should go for it, > thanks Andrew! Yes, this looks good to me as well. The key aspect is documenting the behaviour of these four possibilities. Regards, Anup > > @Yong-Xuan do you think you can prepare another spin with Andrew's > proposal implemented? > > Thanks, > > Alex > > > > > > IOW, I think your proposal is fine except for wanting to document in the > > DT bindings that only svade or svadu may be provided, since I think we'll > > want both to be allowed eventually. > > > > Thanks, > > drew > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@xxxxxxxxxxxxxxxxxxx > > http://lists.infradead.org/mailman/listinfo/linux-riscv
