On Thu, Jul 27, 2023 at 3:42 PM Jan Beulich <jbeul...@suse.com> 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). 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. 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. -George
