Hi Ayan, On 18/05/2023 16:39, Ayan Kumar Halder wrote: > Some Arm based hardware platforms which does not support LPAE > (eg Cortex-R52), uses 32 bit physical addresses. > Also, users may choose to use 32 bits to represent physical addresses > for optimization. > > To support the above use cases, we have introduced arch independent > config to choose if the physical address can be represented using > 32 bits (PHYS_ADDR_T_32) or 64 bits (!PHYS_ADDR_T_32). > For now only ARM_32 provides support to enable 32 bit physical > addressing. > > When PHYS_ADDR_T_32 is defined, PADDR_BITS is set to 32. Note that we > use "unsigned long" (not "uint32_t") to denote the datatype of physical > address. This is done to avoid using a cast each time PAGE_* macros are > used on paddr_t. On 32-bit architecture, "unsigned long" is 32-bit > wide. Thus, it can be used to denote physical address. I think the only issue is when printing but you do not mention it as the root cause. Also, FWIR it all comes down to PAGE_SIZE being defined as L.
I leave it up to you to decide if this is sufficient explanation. Small notice: Generally each commit in a series should build successfully. This is not the case starting from this patch if user (or randconfig) selects 32-bit PA. But I know that other patches depend on PHYS_ADDR_T_32 so I guess it would be difficult. > > When PHYS_ADDR_T_32 is not defined for ARM_32, PADDR_BITS is set to 40. > For ARM_64, PADDR_BITS is set to 48. > The last two are same as the current configuration used today on Xen. > > Signed-off-by: Ayan Kumar Halder <ayan.kumar.hal...@amd.com> Reviewed-by: Michal Orzel <michal.or...@amd.com> ~Michal
