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

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

On 7/27/23 11:15, George Dunlap wrote:
> On Thu, Jul 27, 2023 at 3:42 PM Jan Beulich <jbeulich@xxxxxxxx 
> <mailto: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).
The reality to your scenario here is that it would never work on x86. 
Regardless of which entry point you come in through, 32bit BIOS entry, 
UEFI, or PVH, all of these expect the boot material to be passed in 
using the MB1 or MB2 protocol. Under those protocols, a module 
definition has a start and end addresses which are u32. While the start 
address could be okay, the end address will be well beyond 4GiB which at 
best would overflow the address, but more likely be rejected by the 
bootloader.
> I guess part of the question is whether we think that's an important use 
> case; on the whole if you're populating 5GiB of RAM, it seems like it 
> would be better to have the VM load it itself from disk.
The point of hyperlaunch is to enable advanced use-cases and domain 
resume on boot is one I think someone might find useful.
> I do see the logic behind wanting to avoid "paddr_t" for a size; I'm 
> sure Jan that you would nack any patch that used "size_t" as a memory 
> address (instead of, say, uintptr_t).  In that case, "psize_t" is the 
> obvious solution.
I would be amenable with declaring a psize_t that lived in all the same 
places paddr_t are defined to signal them as a pair, of sorts. I would 
have to see if adding paddr_t and this new psize_t addresses to the 
32bit defs.h would result in making the structures 64bit clean in the 
x86 32bit code. If so, then it would remove the need for a separate 
declaration of the structures there.
v/r,
dps