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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 27.07.2023 20:36, Stefano Stabellini wrote:
> 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.

How can changing size_t be an option? This is determined by the psABI,
and going out of sync with what the compiler assumes size_t is will
bring you all sorts of trouble.

Jan