Re: [PATCH] hvmloader: probe memory below 4G before allocation for OVMF

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 03/04/2020 14:53, Jan Beulich wrote:
> On 02.04.2020 18:18, Igor Druzhinin wrote:
>> The area just below 4G where OVMF image is originally relocated is not
>> necessarily a hole - it might contain pages preallocated by device model
>> or the toolstack. By unconditionally populating on top of this memory
>> the original pages are getting lost while still potentially foreign mapped
>> in Dom0.
> When there are pre-allocated pages - have they been orphaned? If
> so, shouldn't whoever populated them unpopulate rather than
> orphaning them? Or if not - how is the re-use you do safe?

So this is a mess.

OVMF is linked to run at a fixed address suitable for native hardware,
which is in the SPI ROM immediately below the 4G boundary (this is
correct).  We also put the framebuffer there (this is not correct).

This was fine for RomBIOS which is located under the 1M boundary.

It is also fine for a fully-emulated VGA device in Qemu, because the the
framebuffer if moved (re-set up actually) when the virtual BAR is moved,
but with a real GPU (SR-IOV in this case), there is no logic to play games.

The problem is entirely caused by the framebuffer in Xen not being like
any real system.  The framebuffer isn't actually in a BAR, and also
doesn't manifest itself in the way that graphics-stolen-ram normally
does, either.

~Andrew