Page MenuHomeFreeBSD

Implement vm.pmap.kernel_maps for arm64.
ClosedPublic

Authored by markj on Oct 24 2019, 3:26 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 27 2024, 8:18 AM
Unknown Object (File)
Jan 1 2024, 12:38 PM
Unknown Object (File)
Dec 22 2023, 10:44 PM
Unknown Object (File)
Dec 17 2023, 3:12 PM
Unknown Object (File)
Nov 10 2023, 9:14 AM
Unknown Object (File)
Nov 9 2023, 11:33 AM
Unknown Object (File)
Nov 8 2023, 9:17 AM
Unknown Object (File)
Oct 8 2023, 10:28 AM

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj edited the test plan for this revision. (Show Details)
sys/arm64/arm64/pmap.c
6077–6080 ↗(On Diff #63636)

Isn't this referring to an amd64 feature, i.e., the "large map", that we don't have on arm64?

Remove a reference to the large map, copied from amd64.

sys/arm64/arm64/pmap.c
5976 ↗(On Diff #63640)

Could you use ATTR_IDX(VM_MEMATTR_DEVICE) here? It would make it easier to find them later if we add a new memory type.

6080 ↗(On Diff #63640)

Why sva = 0?

Apply reviewer comments.

sys/arm64/arm64/pmap.c
6207 ↗(On Diff #63934)

Please consider adding another column to represent l3pages with ATTR_CONTIGUOUS set. I think that you can simply do the following: If range->attrs has ATTR_CONTIGUOUS set, then (1) divide range->l3pages by 16 and display the quotient in this new column and (2) display zero in the current l3pages column.

6314 ↗(On Diff #63934)

I think that this can move down, past the subsequent "if" statement.

6331 ↗(On Diff #63934)

I think that this can move down, past the subsequent "if" statement.

sys/arm64/arm64/pmap.c
6258 ↗(On Diff #63934)

I suspect that you'll need to include ATTR_CONTIGUOUS here.

markj marked 2 inline comments as done.Nov 6 2019, 5:36 PM
markj added inline comments.
sys/arm64/arm64/pmap.c
6207 ↗(On Diff #63934)

Is there any reason to limit ourselves to L3 pages? From what I can see ATTR_CONTIGUOUS can also be applied to runs of block descriptors. Then, rather than adding an extra column or three, we might format the results as:

<# L1 blocks>(<# contiguous ranges>) <# L2 blocks>(<# contiguous ranges>) <# L3 pages>(<# contiguous ranges>)

or something like that.

sys/arm64/arm64/pmap.c
6207 ↗(On Diff #63934)

In principle, no. You are correct that the architectural specification defines the contiguous bit on L1 and L2 block descriptors when using a 4KB base page size. So, what you propose seems fine.

That said, I can't see how any of the cores that we currently have access to will do anything with a contiguous bit setting on L1 and L2 block descriptors. Cortex-A75's second-level TLB supports 32 MB mappings, and so it could hypothetically do something for contiguous L2 block descriptors.

Count contiguous l3 ranges.

sys/arm64/arm64/pmap.c
6207 ↗(On Diff #63934)

Ok. We can simply add new columns later if need be.

6207 ↗(On Diff #63934)

I implemented this using a different algorithm than what you suggested. In particular, with my change, ATTR_CONTIGUOUS is not recorded as an attribute of the range. This is so that we do not emit multiple lines for a range of addresses that is only partially backed by contiguous blocks. For instance, if we have a 4MB range consisting of one L2 block followed by 512/16 contiguous L3 blocks, I would like the whole range to be printed as a single line.

This revision is now accepted and ready to land.Nov 12 2019, 4:25 AM
This revision was automatically updated to reflect the committed changes.