Messages in this thread | | | Date | Mon, 12 Aug 2019 10:55:41 -0700 | From | Christoph Hellwig <> | Subject | Re: [PATCH] RISC-V: Issue a local tlb flush if possible. |
| |
On Mon, Aug 12, 2019 at 10:36:25AM -0500, Troy Benjegerdes wrote: > Is there anything other than convention and current usage that prevents > the kernel from natively handling TLB flushes without ever making the SBI > call?
Yes and no.
In all existing RISC-V implementation remote TLB flushes are simply implementing using IPIs. So you could trivially implement remote TLB flush using IPIs, and in fact Gary Guo posted a series to do that a while ago.
But: the RISC privileged spec requires that IPIs are only issued from M-mode and only delivered to M-mode. So what would be a trivial MMIO write plus interupt to wakeup the remote hart actually turns into a dance requiring multiple context switches between privile levels, and without additional optimizations that will be even slower than the current SBI based implementation.
I've started a prototype implementation and spec edits to relax this and allow direct IPIs from S-mode to S-mode, which will speed up IPIs by about an order of magnitude, and I hope this will be how future RISC-V implementations work.
> Someone is eventually going to want to run the linux kernel in machine mode, > likely for performance and/or security reasons, and this will require flushing TLBs > natively anyway.
The nommu ports run in M-mode. But running a MMU-enabled port in M-mode is rather painful if not impossible (trust me, I've tried) due to how the privileged spec says that M-mode generally runs without address translation. There is a workaround using the MPRV bit in mstatus, but even that just uses the address translation for loads and stores, and not for the program text.
| |