On Wed, Feb 09, 2022 at 01:37:46PM +0100, Heiko Stuebner wrote: > Svpbmt is an extension defining "Supervisor-mode: page-based memory types" > for things like non-cacheable pages or I/O memory pages. > > > So this is my 2nd try at implementing Svpbmt (and the diverging D1 memory > types) using the alternatives framework. > > This includes a number of changes to the alternatives mechanism itself. > The biggest one being the move to a more central location, as I expect > in the future, nearly every chip needing some sort of patching, be it > either for erratas or for optional features (svpbmt or others). > > The dt-binding for svpbmt itself is of course not finished and is still > using the binding introduced in previous versions, as where to put > a svpbmt-property in the devicetree is still under dicussion. > Atish seems to be working on a framework for extensions [0], > > The series also introduces support for the memory types of the D1 > which are implemented differently to svpbmt. But when patching anyway > it's pretty clean to add the D1 variant via ALTERNATIVE_2 to the same > location. > > The only slightly bigger difference is that the "normal" type is not 0 > as with svpbmt, so kernel patches for this PMA type need to be applied > even before the MMU is brought up, so the series introduces a separate > stage for that. > > > In theory this series is 3 parts: > - sbi cache-flush / null-ptr > - alternatives improvements > - svpbmt+d1 > > So expecially patches from the first 2 areas could be applied when > deemed ready, I just thought to keep it together to show-case where > the end-goal is and not requiring jumping between different series. > > > The sbi cache-flush patch is based on Atish's sparse-hartid patch [1], > as it touches a similar area in mm/cacheflush.c > > > I picked the recipient list from the previous version, hopefully > I didn't forget anybody. > > changes in v6: > - rebase onto 5.17-rc1 > - handle sbi null-ptr differently > - improve commit messages > - use riscv,mmu as property name > > changes in v5: > - move to use alternatives for runtime-patching Hi, another choice is using static key mechanism. Pros: no need to coding in asm, all in c. To support new arch features, I see other arch sometimes use static key, sometimes use alternative mechanism, so one question here would be which mechanism is better? Any guide? Thanks in advance
