> 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 > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#90313): https://edk2.groups.io/g/devel/message/90313 Mute This Topic: https://groups.io/mt/91446026/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
