Hi, > > > 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.
Yes, avoiding hugepages being created in the first place will surely fix that specific case. The commit message should describe the problem better, otherwise I'm fine with the patch. But I think there are more cases where edk2 splits huge pages. HeapGuard comes to mind for example. So I'm wondering whenever there are more simliar problems in the code base. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#90326): https://edk2.groups.io/g/devel/message/90326 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] -=-=-=-=-=-=-=-=-=-=-=-
