Re: [XEN v2 03/11] xen/arm: domain_build: Replace use of paddr_t in find_domU_holes()

[Julien Grall <julien@xxxxxxx>]

On 20/01/2023 09:48, Julien Grall wrote:
> Hi,
>
> On 19/01/2023 23:02, Stefano Stabellini wrote:
> > On Tue, 17 Jan 2023, Ayan Kumar Halder wrote:
> > > bankbase, banksize and bankend are used to hold values of type 'unsigned
> > > long long'. This can be represented as 'uint64_t' instead of 'paddr_t'.
> > > This will ensure consistency with allocate_static_memory() (where we use
> > > 'uint64_t' for rambase and ramsize).
> > >
> > > In future, paddr_t can be used for 'uin32_t' as well to represent 32bit
> > > physical addresses.
> > >
> > > Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>
> > I saw that Julien commented about using unsigned long long. To be
> > honest, given that we typically use explicitly-sized integers (which is
> > a good thing) 
>  From the CODING_STYLE:
>
> "Fixed width types should only be used when a fixed width quantity is
> meant (which for example may be a value read from or to be written to a
> register)."
>
> This is also how we used it in the Arm port so far.
>
> > and unsigned long long is always uint64_t on all
> > architectures, I can see the benefits of using uint64_t here.
>  From my understanding of the C spec, the only requirement is that 
> "unsigned long long" can fit a 2^64 - 1. So it may technically be bigger 
> than 64-bit.
> > At the same time, I can see that the reason for change the type here is
> > that we are dealing with ULL values, so it would make sense to use
> > unsigned long long. >
> > I cannot see any big problem/advantages either way, so I am OK with
> > this patch. (Julien, if you prefer unsigned long long I am fine with
> > that also.)
> I don't mind too much here.
>
> > Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
Committed.

Cheers,

--
Julien Grall