On 2/18/25 14:40, Valentin Schneider wrote: >> In practice, it's mostly limited like that. >> >> Architecturally, there are no promises from the CPU. It is within its >> rights to cache anything from the page tables at any time. If it's in >> the CR3 tree, it's fair game. >> > So what if the VMEMMAP range *isn't* in the CR3 tree when a CPU is > executing in userspace? > > AIUI that's the case with kPTI - the remaining kernel pages should mostly > be .entry.text and cpu_entry_area, at least for x86. Having part of VMEMMAP not in the CR3 tree should be harmless while running userspace. VMEMMAP is a purely software structure; the hardware doesn't do implicit supervisor accesses to it. It's also not needed in super early entry. Maybe I missed part of the discussion though. Is VMEMMAP your only concern? I would have guessed that the more generic vmalloc() functionality would be harder to pin down.
