> This makes sense, but, again, even disregarding the problem that the
> code forgot to switch to the new page table, the idea should be spelled
> out in the commit message and/or in code comments. Preferably: both.
>
> (In fact if the idea had been documented, Yuanhao might not have
> forgotten to implement the switch.)
>
But the following cases still require the XD bit be removed from the active
page table:
*. 32bit mode
In fact, old 32bit logic contains a bug that paging might still be enabled
when AP is in the idle loop.
That's a long-exist bug. QEMU doesn't enable the memory protection feature
resulting the paging is disabled in 32bit mode.
Hence the bug doesn't appear in QEMU 32bit image.
Yuanhao's logic tries to not create page table for 32bit mode. I agree with
this because it simplifies the 32bit flow.
But considering the paging might be enabled, XD removal logic should be
kept.
*. 64bit AMD
Today Yuanhao's logic tries to not modify AMD 64bit flow no matter SEV is
enabled or not.
But if the BSP page table is used by AP when running the code in the
reserved memory, the XD bit removal logic should be
kept for 64bit AMD.
So, that means only 64bit Intel flow doesn't require the XD bit removal
logic.
Then, for code simplicity (reducing the branches), I recommend keeping the
XD bit removal logic always.
Imaging in a long future that 32bit x86 support is removed from edk2 and the
legacy SEV is removed as well, we can cleanup
the unnecessary XD bit removal then.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98094): https://edk2.groups.io/g/devel/message/98094
Mute This Topic: https://groups.io/mt/96067843/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
