Re: [PATCH] revert "hvmloader: PA range 0xfc000000-0xffffffff should be UC"

[Andrew Cooper <amc96@xxxxxxxx>]

On 16/12/2021 11:09, Roger Pau Monné wrote:
> On Thu, Dec 16, 2021 at 11:00:17AM +0000, Andrew Cooper wrote:
>> On 16/12/2021 09:54, Roger Pau Monné wrote:
>>> On Tue, Dec 14, 2021 at 09:21:22AM +0100, Jan Beulich wrote:
>>>> This reverts commit c22bd567ce22f6ad9bd93318ad0d7fd1c2eadb0d.
>>>>
>>>> While its description is correct from an abstract or real hardware pov,
>>>> the range is special inside HVM guests. The range being UC in particular
>>>> gets in the way of OVMF, which places itself at [FFE00000,FFFFFFFF].
>>> I would assume this range to be unpopulated? Does hvmloader populate
>>> it in order to place ovmf?
>> It's generally not unpopulated.  The video RAM lives there until the VGA
>> BAR is reprogrammed.
> Right, but that's an MMIO area from guests PoV, even if in our
> implementation is backed by RAM pages.
>
>> The reason OVMF places itself there is because it is where the real SPI
>> ROM is mapped in address space on a real system.
> Just to clarify my understanding, this is not reported as a RAM region
> to guests? So hvmloader or the domain builder populates this with RAM
> to place OVMF, even if not reported as a RAM region in the memory map
> (much like with ACPI tables for example).
>
> I wonder whether we should have some kind of document or code comment
> about the guest memory layout (maybe there's one and I'm missing it).

Like most things with guest physmap handling, it's broken and held
together with hope.

Yes, it's logically an MMIO region, but actually "just plain RAM" under
the hood.

What should happen is the domain builder place OVMF there directly. 
OVMF is linked to run there, and there ought to be no hvmloader involved
for UEFI guests, and there shouldn't be any copying into place
required.  That was a very short sited move on behalf of the OVMF
support logic, and I guarantee you that it creates more problems than it
allegedly solves.

~Andrew