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?
> While this is benign to epte_get_entry_emt() as long as the IOMMU isn't
> enabled for a guest, it becomes a very noticable problem otherwise: It
> takes about half a minute for OVMF to decompress itself into its
> designated address range.
>
> And even beyond OVMF there's no reason to have e.g. the ACPI memory
> range marked UC.
>
> Fixes: c22bd567ce22 ("hvmloader: PA range 0xfc000000-0xffffffff should be UC")
> Signed-off-by: Jan Beulich <[email protected]>
Reviewed-by: Roger Pau Monné <[email protected]>
This is just a hole from hvmloader PoV, so it's fine to not apply any
specific MTRR attributes.
Thanks, Roger.
