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). Thanks, Roger.
