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? > The only area of issue for x86 is during the short bit of > code that runs in 32bit mode during startup. In this series, we address > this by using a set of macros in the 32bit code to provide 64bit clean > definition of the structures. This approach is acceptable because as far > as I am aware, x86 is the only platform where the hypervisor has to > transition from one bit size to another, e.g. Arm just starts in 64bit > mode when on a 64bit device. > > At the end of the day, size_t is the same size as paddr_t for the end > execution environments and I would levy a guess that should x86 suddenly > find itself having a 128bit mode which would likely drive paddr_t to > 128bits, so would follow size_t. Likely. Yet when we still had ix86 (x86-32) support, paddr_t also wasn't the same as size_t. Even on x86-64 it's possible we'd see physical address width go beyond 64 bits before virtual address width would, just like had happened for ix86 (which initially only allowed for 32-bit physical addresses, until PSE36 arrived). In your implementation you want to cover the general case, not a subset of special ones. Jan
