Re: [PATCH] Add direct memory access synchronize extension

Nick Kossifidis

Στις 2021-06-04 23:01, Atish Patra έγραψε:
The firmware code will still be executed while the priv mode is S-mode
right ?
Wouldn't that violate the priv spec ?
M-mode can share a code region with S-mode using PMP/ePMP and let S-mode map that region as executable on its address space. With the current PMP M-mode can define a region as RX for example and both M-mode and S/U-mode will have RX permissions there, with ePMP M-mode can share a code region with S/U-mode that can be RX for M-mode and just X for S/U-mode. I'm obviously talking about small code snippets without any dependencies and references to external symbols etc. A function that flushes the cache for example can be written in such a way.

I'm not very
passionate about this, after all an ecall isn't that expensive and a
sync is not an operation that happens very frequently, but maybe it's a
good opportunity to talk about this approach.
That's what I am thinking. The only additional cost is just a "ecall
and mret".
IMO, there will be noticeable difference in performance in vDSO-like
interface where S-mode is trying to read something that M-mode
provides. Thus, the base function list are likely candidates [1].
However, the OS makes those SBI calls once during the boot. Thus, it
wouldn't benefit that much.
I was thinking that as part of the extension, we can have an SBI call that would return the address/length of the shared code region (in physical memory) and offsets for each function within that region. The OS will do the SBI call upon registering that SBI extension and will just use the provided function pointers to directly execute code from the shared region. If we are looking for a scenario with a high rate of syncs (lots of packets per second) there will be a noticeable performance difference between a function call and an SBI call, on the other had on such scenarios I'd expect to use the coherent API instead of the non-coherent one.

Join to automatically receive all group messages.