Otherwise we can fail to handle translation faults on curthread, leading
to a panic.
I don't really like this solution, but without it I readily get random
panics under QEMU.
Differential D23895 Authored by markj on Feb 29 2020, 5:49 PM.
Details Summary Otherwise we can fail to handle translation faults on curthread, leading I don't really like this solution, but without it I readily get random
Diff Detail
Event TimelineHarbormaster completed remote builds in B29692: Diff 68996.Feb 29 2020, 5:49 PM2020-02-29 17:49:15 (UTC+0) Comment Actions The _NOFREE reminds me that we still need a way to segregate _NOFREE allocations in physical memory. Such segregation would most likely provide contiguity inherently. This revision is now accepted and ready to land.Feb 29 2020, 6:01 PM2020-02-29 18:01:32 (UTC+0) Comment Actions
The freepool approach requires some work in order to segregate KVA allocations, I believe, but I think that should be straightforward.
I would like to but probably won't in the near future - I found this bug while investigating another bug which is blocking a project I'm working on. I will try to return to this later. Comment Actions
Consider this alternative. We create a second backend to kmem allocations that doesn't do normal reservation-based allocations but preemptively allocates the whole 2MB of physical memory and maps it as such before handing out any KVAs from the region. A vmem arena, submap, etc. could then be used to dole out the unused addresses within the region. As a backstop, if we can't allocate a contiguous 2MB of physical memory, we fall back to smaller allocations. Closed by commit rS358470: Ensure that arm64 thread structures are allocated from the direct map. (authored by markj). · Explain WhyFeb 29 2020, 6:42 PM2020-02-29 18:42:05 (UTC+0) This revision was automatically updated to reflect the committed changes. Herald added a subscriber: imp. · View Herald TranscriptFeb 29 2020, 6:42 PM2020-02-29 18:42:06 (UTC+0) Comment Actions
I wrote a patch which implements this using a per-domain vmem arena. At the moment it falls back to the regular allocation path if we fail to import 2MB of physical memory: vmem import functions are currently required to return exactly the amount requested. I guess we could work around this with a function to manually add smaller chunks of contiguous memory to the arena when an allocation fails, instead of using the import mechanism.
Revision Contents
Diff 69001 head/sys/kern/kern_thread.c
|
I would be interested in implementing this, but not sure how soon that would be...