[edk2-devel] [PATCH] UefiPayloadPkg: Always split page table entry to 4K if it covers stack.

[Gerd Hoffmann]

  Hi,

> yes:) Actually there is no split at all. The 4K page table is created in the very beginning(before setting to cr3).
> So, no TLB cache issue at all.

> > I think doing a linux-style page split will be the more robust solution.
> 
> Thanks for explaining the linux behavior.
> 
> Intel's SDM also contain below wordings:
> * As noted in Section 4.10.2, the TLBs may subsequently contain multiple translations for the address range if
> * software modifies the paging structures so that the page size used for a 4-KByte range of linear addresses
> * changes. A reference to a linear address in the address range may use any of these translations.

This is probably the section the "only safe if [ ... ] the two entries
[ ... ] identical" part refers to.

> * Software wishing to prevent this uncertainty should not write to a paging-structure entry in a way that would
> * change, for any linear address, both the page size and either the page frame, access rights, or other attributes.
> * It can instead use the following algorithm: first clear the P flag in the relevant paging-structure entry (e.g.,
> * PDE); then invalidate any translations for the affected linear addresses (see above); and then modify the
> * relevant paging-structure entry to set the P flag and establish modified translation(s) for the new page size.

So linux basically implements this recommendation.

> But I still have some doubts about using linux-style page split.
> Because it's marked as not present:
> 1. Active code should not access data in the 2M region (stack is in the 2M region in our case)
> 2. Active code should not in the 2M region (how to guarantee that?)
> 
> How does Linux guarantee the above two points?

Easy.  It's kernel code changing mappings for userspace, so no need to
worry about code removing its own mappings in the first place.  It's a
different story for edk2 though ...

Can this be covered by the page fault handler?  Update the entry like
the current code does, except for clearing the present bit, then flush
tlb, then set the present bit.  In case we take a page fault the only
action the handler must do is enable the present bit, which might even
be possible to do without additional state tracking.

Linux most likely has something simliar in the page fault handler.
Linux needs it for a different reason, it must handle SMP races.  When
temporary clearing the present bit linux might get a page fault on
*another* cpu which runs userspace code touching the page being updated.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#90107): https://edk2.groups.io/g/devel/message/90107
Mute This Topic: https://groups.io/mt/91446026/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-