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)
Mon, Jun 3, 9:35 PM
Unknown Object (File)
Wed, May 22, 5:04 AM
Unknown Object (File)
Wed, May 22, 5:02 AM
Unknown Object (File)
Wed, May 22, 3:43 AM
Unknown Object (File)
Wed, May 22, 3:24 AM
Unknown Object (File)
Tue, May 21, 12:26 PM
Unknown Object (File)
Sun, May 19, 8:57 AM
Unknown Object (File)
Sun, May 19, 8:57 AM

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 27446
Build 25684: arc lint + arc unit

Event Timeline

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

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
6184

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.

6288

Why sva = 0?

Apply reviewer comments.

sys/arm64/arm64/pmap.c
6204

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.

6311

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

6328

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

sys/arm64/arm64/pmap.c
6255

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
6204

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
6204

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
6204

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

6204

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.