riscv: explicit memory barrier primitives

[mengzhuo1203_gmail.com]

Summary

FreeBSD didn't follow Linux premitives as RISC-V spec required
we use smp_(r|w)mb

|     	| FreeBSD 	| Linux      	|
|-----	|---------	|------------	|
| mb  	| rw, rw  	| iorw, iorw 	|
| rmb 	| r, r    	| ior, ior   	|
| wmb 	| w, w    	| iow, iow   	|

This change explicit this difference.

PR 290249

[jrtc27]

Do we actually have a proper definition of what *our* memory barrier APIs are meant to mean? What the ISA manual says is a sensible mapping isn't necessarily what we want; note that the table you're referencing is for "Linux memory primitives", and we are not Linux, nor do we follow its memory model.

sys/riscv/include/atomic.h

41

I'm surprised this even works, but I guess if " is just a token to the preprocessor I can kind of see how it might (though would expect the space to go missing). Surely it should be "fence "#PRE", "#SUC?

[mengzhuo1203_gmail.com]

In D53232#1216063, @jrtc27 wrote:

Do we actually have a proper definition of what *our* memory barrier APIs are meant to mean? What the ISA manual says is a sensible mapping isn't necessarily what we want; note that the table you're referencing is for "Linux memory primitives", and we are not Linux, nor do we follow its memory model.

Thanks for review, it's first time that I contribute to kernel and I trying to fix the https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290249

I found those definitions are essential to busdma (sys/riscv/riscv/busdma_bounce.c), I will send those diffs later.

As for memory barrier APIs, I can't find them though Google and gpts, can you send the links for me?

Thanks

[mengzhuo1203_gmail.com]

@jrtc27 I've update the revision, PTAL

[jrtc27]

This will not fix that bug. fence is fence iorw, iorw, so all you are doing is relaxing some ordering requirements.

[mengzhuo1203_gmail.com]

In D53232#1216532, @jrtc27 wrote:

This will not fix that bug. fence is fence iorw, iorw, so all you are doing is relaxing some ordering requirements.

Done.