On 20/12/2024 5:53 pm, Shawn Anastasio wrote:
> Xen's memory management APIs map_pages_to_xen, modify_xen_mappings,
> set_fixmap, ioremap_attr, and __vmap all use an unsigned int to
> represent architecture-dependent page table entry flags. This assumption
> does not work on PPC/radix where some flags go past 32-bits, so update
> these APIs to use unsigned long for flags instead.
>
> Signed-off-by: Shawn Anastasio <sanasta...@raptorengineering.com>
Funnily enough, the same is true on x86 too. NX and ProtKey bits are
from bit 63 downwards.
x86 funnels all PTE flags through {get,put}_pte_flags() which compresses
a 64bit PTE's flags (top and bottom 12 bits) into a 24 bit number.
This was allegedly for the benefit of 32bit builds of Xen with PAE
paging. I'm not convinced this claim was backed up evidence, even in
the 32bit days, because the areas of code working on flags separately
from a 64bit PTE are minimal.
Nevertheless, it's been 11 years since we dropped x86_32, and it's
definitely tech debt and unnecessary overhead in x86_64.
I firmly support making this adjustment. It's been on my todo list for
years, but never high enough to get started.
However, instead of just a plain unsigned long, perhaps we should have a
concrete type, perhaps pte_attr_t ?
This lets different architectures handle things differently, and also
lets us make it TYPE_SAFE() like mfn and friends.
Most importantly though, it makes it less likely that we're going to end
up with paths that accidentally have some long->int truncation.
Thoughts?
~Andrew
