On Thu, May 30, 2024 at 11:01:20AM GMT, Alexandre Ghiti wrote:
Hi Andrew,Hmm, yeah we're probably pretty safe since sorting this out is just one of
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,Unfortunately I joined yesterday's patchwork call late and missed this
On 27/05/2024 18:25, Andrew Jones wrote:
On Fri, May 24, 2024 at 06:33:01PM GMT, Yong-Xuan Wang wrote:So we talked about this yesterday during the linux-riscv patchwork meeting.
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.
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.
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.
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.
I think we should have documented behaviors for all four possibilities
This is what you did in your previous versions ofI'm not sure firmware will be able to choose svadu when it's available.
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.
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.
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.
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