Re: [PATCH 03/10] x86 setup: change bootstrap map to accept new boot module structures

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 27 Jul 2023, George Dunlap wrote:
> On Thu, Jul 27, 2023 at 3:42 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>       On 27.07.2023 15:26, Daniel P. Smith wrote:
>       > Let's bring this back to the actual implementation instead of the
>       > theoretical. Your position is that Xen's paddr_t is desired because it
>       > can store larger values than that of size_t. Now if you look in Xen
>       > proper (main 64bit code on x86), paddr_t is a typedef for a 64bit
>       > unsigned integer. And if you look at size_t, it is also a typedef to a
>       > 64bit unsigned integer, they are literally a couple of lines apart in
>       > types.h. Thus they are the same size and can only represent the same
>       > maximum size.
> 
>       What about 32-bit Arm, or any other 32-bit architecture that we might
>       see Xen ported to, with wider than 32-bit physical address space?
> 
> 
> To be more concrete here:
> 
> Suppose that you had a machine with 32-bit virtual address spaces (i.e., 
> going up to 4GiB), and 36-bit physical address spaces (i.e., going
> up to 64GiB).  And suppose you had a system with 16GiB of physical ram.  And 
> you wanted to use Hyperlaunch to create VMs using some sort of
> memory image that was 5GiB (presumably of some kind of static data, not, say, 
> a kernel or initramfs).  You wouldn't be able to do it if the
> "size" parameter of the boot modules was limited to 4GiB (without some kind 
> of hack where you string multiple boot modules together).

Yes exactly.

I would like this code to be common across ARM and x86. On arm32 size_t
wouldn't work, with size_t as it is defined today. One option is to use
paddr_t on all arches, or at least on arm32. Another option is to change
the definition of size_t on arm32.

My suggestion it to move the existing equivalent dom0less interface
defined here:
xen/arch/arm/include/asm/setup.c:struct bootmodule
to common code and base this work on top of it. struct bootmodule uses
paddr_t for both start and size to solve the arm32 issue today.