Re: [XEN v2 09/11] xen/arm: Introduce ARM_PA_32 to support 32 bit physical address

[Ayan Kumar Halder <ayankuma@xxxxxxx>]

Hi Jan,

On 18/01/2023 08:50, Jan Beulich wrote:
> On 17.01.2023 18:43, Ayan Kumar Halder wrote:
> > --- a/xen/arch/arm/include/asm/types.h
> > +++ b/xen/arch/arm/include/asm/types.h
> > @@ -37,9 +37,16 @@ typedef signed long long s64;
> >   typedef unsigned long long u64;
> >   typedef u32 vaddr_t;
> >   #define PRIvaddr PRIx32
> > +#if defined(CONFIG_ARM_PA_32)
> > +typedef u32 paddr_t;
> > +#define INVALID_PADDR (~0UL)
> > +#define PADDR_SHIFT BITS_PER_LONG
> > +#define PRIpaddr PRIx32
> > +#else
> With our plan to consolidate basic type definitions into xen/types.h
> the use of ARM_PA_32 is problematic: Preferably we'd have an arch-
> independent Kconfig setting, much like Linux'es PHYS_ADDR_T_64BIT
> (I don't think we should re-use the name directly, as we have no
> phys_addr_t type), which each arch selects (or not) accordingly.
> Perhaps architectures already selecting 64BIT wouldn't need to do
> this explicitly, and instead 64BIT could select the new setting
> (or the new setting could default to Y when 64BIT=y).
Looking at some of the instances where 64BIT is currently used 
(xen/drivers/passthrough/arm/smmu.c), I understand that it is used to 
define the width of **virtual** address.
Thus, it would not conflict with ARM_PA_32 (which is for physical address).

Later on if we wish to introduce something similar to Linux's 
PHYS_ADDR_T_64BIT (which is arch agnostic), then ARM_PA_32 can be 
selected by "!PHYS_ADDR_T_64BIT" && "CONFIG_ARM_32". (We may decide to 
drop ARM_PA_32 config option, but we can still reuse ARM_PA_32 specific 
changes).
Also, then we will need to support 32 bit physical address (ie 
!PHYS_ADDR_T_64BIT) with 32 bit virtual address (ie !64BIT) and 64 bit 
virtual address (ie 64BIT).
Let's confine the current changes to Arm architecture only (as I don't 
have knowledge about x86 or RISCV). When similar changes will be done 
for other architectures, then we can think about introducing an 
architecture agnostic option.
- Ayan

> Jan