> On May 11, 2020, at 12:14 PM, Joerg Roedel <jroedel@xxxxxxx> wrote: > > On Mon, May 11, 2020 at 08:36:31AM -0700, Andy Lutomirski wrote: >> What if we make 32-bit PTI depend on PAE? > > It already does, PTI support for legacy paging had to be removed because > there were memory corruption problems with THP. The reason was that huge > PTEs in the user-space area were mapped in two page-tables (kernel and > user), but A/D bits were only fetched from the kernel part. To not make > things more complicated we agreed on just not supporting PTI without > PAE. > >> And drop 32-bit Xen PV support? And make 32-bit huge pages depend on >> PAE? Then 32-bit non-PAE can use the direct-mapped LDT, 32-bit PTI >> (and optionally PAE non-PTI) can use the evil virtually mapped LDT. >> And 32-bit non-PAE (the 2-level case) will only have pointers to page >> tables at the top level. And then we can preallocate. > > Not sure I can follow you here. How can 32-bit PTI with PAE use the LDT > from the direct mapping? I am guessing you want to get rid of the > SHARED_KERNEL_PMD==0 case for PAE kernels. I wrote nonsense. I mean bite off a piece of the *user* portion of the address space and stick the LDT there. I contemplated doing this when I wrote the 64-bit code, but I decided we had so much address space to throw around that I liked my solution better. > This would indeed make > syncing unneccessary on PAE, but pre-allocation would still be needed > for 2-level paging. Just the amount of memory needed for the > pre-allocated PTE pages is half as big as it would be with PAE. > >> Or maybe we don't want to defeature this much, or maybe the memory hit >> from this preallocation will hurt little 2-level 32-bit systems too >> much. > > It will certainly make Linux less likely to boot on low-memory x86-32 > systems, whoever will be affected by this. > > I’m guessing the right solution is either your series or your series plus preallocation on 64-bit. I’m just grumpy about it...
