Page MenuHomeFreeBSD

riscv: Svpbmt extension support
Needs ReviewPublic

Authored by mhorne on Jun 3 2024, 6:51 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Jul 9, 6:54 AM
Unknown Object (File)
Mon, Jul 8, 2:43 AM
Unknown Object (File)
Sat, Jul 6, 8:38 PM
Unknown Object (File)
Fri, Jul 5, 12:29 PM
Unknown Object (File)
Tue, Jul 2, 1:30 PM
Unknown Object (File)
Sat, Jun 29, 12:06 AM
Unknown Object (File)
Fri, Jun 28, 9:56 AM
Unknown Object (File)
Wed, Jun 26, 3:47 PM
Subscribers

Details

Reviewers
markj
br
jrtc27
jhb
Group Reviewers
riscv
Summary

The Svpbmt extension provides specification of "Page-Based Memory
Types", or memory attributes (e.g. cacheability constraints).

Extend pmap code to apply memory attributes when creating/updating PTEs.
This is done in a way which should be non-hostile to CPUs lacking memory
attribute (Svpbmt) support, and applicable to alternate encodings of
this feature (T-HEAD CPUs, see next review).

Test Plan

Basic smoketest in a VM with 'Svpbmt' extension enabled: this only has a couple mappings marked "I/O" in sysctl vm.pmap.kernel_maps.

pmap_change_attr() is not widely used, so to test this I swapped some driver malloc() calls to allocate memory/KVA but map it as VM_MEMATTR_NOCACHE. This seemed to work fine and the DMAP was updated accordingly, forcing a demotion of the L1 page created by pmap_bootstrap_dmap().

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 58278
Build 55166: arc lint + arc unit

Event Timeline

mhorne requested review of this revision.Jun 3 2024, 6:51 PM
sys/riscv/riscv/pmap.c
4884

Could you pull memattr_mask down into this commit? We'll need it in CheriBSD, as our existing CHERI-RISC-V spec collides with Svpbmt (there was no space to do custom extensions at the time we wrote it, so picked the high bits thinking the standard bits would be allocated from the bottom not the top...). That will eventually change as we move towards standardising within RISC-V, but we haven't got a draft spec for PTEs yet, and even then it's going to be a big lift to switch everything over to the draft standard encodings, mnemonics, PTEs, etc.

sys/riscv/riscv/pmap.c
4884

Certainly, I can do that.

Generally looks good to me.

sys/riscv/riscv/pmap.c
544

One of my suggestions didn't get added and I have to add a dummy comment to add it.

sys/riscv/riscv/pmap.c
3421

You can remove the commented out line?

Finish implementation of pmap_change_attr_locked().

Bring in memattr_mask from the T-HEAD child review.

mhorne retitled this revision from [DRAFT/RFC] riscv: Svpbmt extension support to riscv: Svpbmt extension support.Tue, Jun 18, 6:15 PM
mhorne edited the summary of this revision. (Show Details)
mhorne edited the test plan for this revision. (Show Details)
sys/riscv/riscv/pmap.c
4947

Note: I do think it is possible to collapse this into the first loop, but I had a difficult time expressing this cleanly. This is not a performance critical path.

4965–4970

This logic could be improved to batch updates to the DMAP, akin to amd64's implementation. For now I did the simple thing.

Apply memattr bits to mappings created at the end of pmap_bootstrap() (this was missed).