On 22.06.2021 17:39, Andrew Cooper wrote: > This reverts commit aad7b5c11d51d57659978e04702ac970906894e8. > > The change from OvmfX64 to OvmfXen causes a change in behaviour, whereby > OvmfXen maps its shared info page at the top of address space. When trying to > migrate such a domain, XENMEM_maximum_gpfn returns a very large value. This > has uncovered multiple issues: > > 1) The userspace hypercall wrappers truncate all return values to int on > Linux and Solaris. This needs fixing in Xen. > 2) 32bit toolstacks can't migrate any domain with RAM above the 2^40 mark, > because of virtual address constraints. This needs fixing in OVMF.
And I suspect even that presently enforce boundary of 2^40 is actually too high, and things still wouldn't work when getting close. At the very least the tool stack then depends on a fairly big chunk of memory (2^30 bytes) to be available in one single, virtually contiguous piece. Iirc 32-bit Linux can be configured to not even leave this much space for user mode. Jan
