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)
Wed, Oct 30, 9:23 AM
Unknown Object (File)
Sun, Oct 20, 11:19 AM
Unknown Object (File)
Fri, Oct 4, 9:36 PM
Unknown Object (File)
Sep 20 2024, 1:33 PM
Unknown Object (File)
Sep 10 2024, 1:29 PM
Unknown Object (File)
Sep 5 2024, 10:02 AM
Unknown Object (File)
Sep 5 2024, 5:51 AM
Unknown Object (File)
Aug 25 2024, 1:18 PM

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 27200
Build 25466: arc lint + arc unit

Event Timeline

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

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

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

Why sva = 0?

Apply reviewer comments.

sys/arm64/arm64/pmap.c
5996

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.

6103

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

6120

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

sys/arm64/arm64/pmap.c
6047

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
5996

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
5996

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
5996

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

5996

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.