[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.