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 <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). > > 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
