Page MenuHomeFreeBSD

Don't fail changing props for unmapped DMAP memory
ClosedPublic

Authored by andrew on Dec 15 2021, 11:04 AM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 14 2024, 4:55 AM
Unknown Object (File)
Jan 12 2024, 3:09 PM
Unknown Object (File)
Dec 23 2023, 12:24 AM
Unknown Object (File)
Nov 27 2023, 1:47 AM
Unknown Object (File)
Sep 29 2023, 12:23 AM
Unknown Object (File)
Sep 5 2023, 6:00 PM
Unknown Object (File)
Jun 12 2023, 3:26 AM
Unknown Object (File)
May 29 2023, 2:33 AM
Subscribers

Details

Summary

When recursing in pmap_change_props_locked we may fail because there is
no pte. This shouldn't be considered a fail as it may happen in a few
cases, e.g. there are multiple normal memory ranges with device memory
between them.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 43497
Build 40385: arc lint + arc unit

Event Timeline

Assuming this is the patch I saw yesterday, it unbreaks the ENA driver..

It's an updated version, so might break it again (but hopefully not). It will now skip over unmapped memory rather than return early.

Just tested the latest version; works fine.

This revision is now accepted and ready to land.Dec 15 2021, 3:45 PM
sys/arm64/arm64/pmap.c
6038
sys/arm64/arm64/pmap.c
555

The last sentence of this comment isn't accurate now.

558

There is a very similar function in arm64/iommu/iommu_pmap.c that still has the old behaviour w.r.t. setting *level when a PTE is missing. I think it would be better to keep them consistent.

590

The assertion lvl == 3 in pmap_qremove() doesn't catch some erroneous cases now.

sys/arm64/arm64/pmap.c
558

I think I was confused and the code was correct, however it should start with pmap_l0 so we can skip over the l0 entry if it's unmapped.

590

Should be fixed in D33509

sys/arm64/arm64/pmap.c
558

I also think that the code was correct, and that that the proposed changes to pmap_pte() should be undone.

This revision now requires review to proceed.Dec 20 2021, 10:12 AM
This revision is now accepted and ready to land.Dec 21 2021, 4:58 AM

So for the case of setting memory as uncacheable (when wbinv_range() is called), do you end up calling this function on unmapped range? Does it work on arm64?

We only ever call wbinv_range when ptep != NULL so a mapping will exist for the current virtual address. If the DMAP is unmapped the caller will perform the cache management. If the DMAP is mapped cpu_dcache_wbinv_range will be called twice, once for the non-DMAP, and once for the DMAP memory.