This allows to check that the entire object falls into the direct map.
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 51834 Build 48725: arc lint + arc unit
Event Timeline
Comment Actions
I think it would be cleaner to have macro like PHYS_SZ_IN_DMAP(pa, sz) which would check for [pa, pa+sz) belonging to the DMAPed region.
Comment Actions
Added the PHYS_SZ_IN_DMAP macro as requested.
Currently this is only added for arm64 and amd64, which are the platforms that use it.
I'm not sure what the policy is in this case, should I add the same macro for other archs to keep the interface consistent?
Comment Actions
Only add the macro where needed.
| sys/amd64/include/vmparam.h | ||
|---|---|---|
| 247 | No, this is not what I mean. PHYS_SZ_IN_DMAP(pa, sz) should verify that [pa, ps+sz) is mapped by DMAP. | |
| sys/amd64/include/vmparam.h | ||
|---|---|---|
| 248 | Should the check verify pa+sz-1 instead of pa+sz? Consider the last page in the DMAP, at the address x. If you want to check if the whole page belongs to DMAP-mapped region, you would check the x+PAGE_SIZE address, which lives in the next page not covered by DMAP. | |
| sys/amd64/include/vmparam.h | ||
|---|---|---|
| 248 | Uh, yes I think it should, the check in PHYS_IN_DMAP uses strict inequality for (pa) < dmaplimit. | |
| sys/amd64/include/vmparam.h | ||
|---|---|---|
| 247 | FYI, downstream in CheriBSD we have found uses for this on RISC-V as well, so I had suggested to Alfredo to move this to <vm/vm_param.h>. While PHYS_IN_DMAP is inherently MD, this new macro is not. | |
Comment Actions
One final suggestion on naming might be to call the new macro DMAP_CONTAINS to match the pattern from the recently added kstack_contains function.
Comment Actions
That could be confused with testing whether a virtual address is within the DMAP mapping.
| sys/vm/vm_param.h | ||
|---|---|---|
| 136 ↗ | (On Diff #123446) | You do not need this guard for #define. |
| sys/vm/vm_param.h | ||
|---|---|---|
| 136 ↗ | (On Diff #123446) | I'll drop the guard if it isn't necessary. I think vm_param.h seems a more natural place since the original definitions are in machine/vmparam.h instead of machine/pmap.h, but I can move it if avoiding extra includes is a priority. |
| sys/vm/vm_param.h | ||
|---|---|---|
| 136 ↗ | (On Diff #123446) | About vm_param.h vs pmap.h, I do not insist, it was only a suggestion. |
| sys/vm/vm_param.h | ||
|---|---|---|
| 136 ↗ | (On Diff #123446) | I had guessed at vm/vm_param.h when suggesting to move this downstream due to the machine/vmparam.h for the original location, but vm/pmap.h might indeed be the better header? I can never remember which headers to actually include for the DMAP macros and tend to just start adding more vm/*.h until it compiles. :( We could really use a DMAP.9 or the like that described the API and gave the suggested #includes to use, etc. |