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

[Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>]

On 03/04/2020 15:39, Andrew Cooper wrote:
> 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.

Adding to what Andrew said:

There multiple technical complications that caused this mess.
One of them is that there is no unfortunately a better place for the
framebuffer to be located initially. Second, SR-IOV device
is real and adding a virtual BAR to it is also complicated (due to
compatibility reasons) and NVIDIA decided to avoid that.

Igor