On 06.02.23 07:33, Juergen Gross wrote:
> I still don't see why the original report of Christian is making sense:
> 
> According to the error message, the _requested_ memory type was UC-, but
> the reverted patch only affects cases where the requested type is WB. So
> why does a revert of 90b926e68f50 is helping to make this message go away?
> The message was:
> 
>    ioremap error for 0xf2520000-0xf2530000, requested 0x2, got 0x0
> 
> Meanwhile I've found a system which is issuing such a message under Xen.
> I'll investigate further _why_ a request of UC- ends up to get WB.

Okay, here the result of my investigation:

During ACPI initialization ACPI code seems to try mapping a memory area
being marked as "reserved" in the memory map with type WB (this happens
in acpi_os_map_iomem()).

With commit 90b926e68f50 this is now accepted, resulting in this memory
area being registered with the WB type.

Much later the driver for the device owning this reserved memory area
tries to map the area as UC-, but it gets WB due to the much earlier
mapping via acpi_os_map_iomem().

Before commit 72cbc8f04fe2 (which 90b926e68f50 tried to fix) this whole
mess worked, because memtype_reserve() took the early exit due to
pat_enabled() returning false.

Just reverting 90b926e68f50 will reintroduce the TDX guest issue Michael
reported (massive slow down due to getting memory areas mapped as UC-).

I believe the most promising way out of this mess would be to let
interested parties (Xen guests, Hyper-V TDX guests) set the MTRR memory
type they want to get back from mtrr_type_lookup() for the cases it
returns MTRR_TYPE_INVALID today.

I guess Xen Dom0 would specify MTRR_TYPE_UNCACHABLE, while Hyper-V TDX
guests could set it to MTRR_TYPE_WRBACK.

Any thoughts?


Juergen