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

["Ni, Ray" <ray.ni@intel.com>]

>   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.

It's a bit heavy from my perspective.
I prefer to split the page to 4K in the very beginning of stack setup.
It also guarantees such issue doesn't appear.

> 
> 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
> 
> 
> 
> 
>