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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 22/06/2021 17:10, Jan Beulich wrote:
> 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.

I tested it once during Migration v2 development, and it worked for me,
but I do expect that that is as much testing as it has had since...

A 3G/1G split is the default under multiple 32bit kernels, and the
allocation is made right at the start, so there is a reasonable chance
of finding space.  After all, it only needs 4k alignment.

Whether ASLR has changed the chances in the meantime remains to be seen,
but honestly - 32bit toolstacks on x86 really don't exist in production
any more, and Arm still hasn't implemented logdirty support, so the
limit has little practical consequence.

~Andrew