Re: [PATCH] Revert "tools/firmware/ovmf: Use OvmfXen platform file is exist"

[Jan Beulich <jbeulich@suse.com>]

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