archive mirror
 help / color / mirror / Atom feed
From: Juergen Gross <>
To: Linus Torvalds <>,
	Borislav Petkov <>
Cc: Christian Kujau <>,
	Michael Kelley <>,,
	Greg KH <>,
	Linux regressions mailing list <>
Subject: Re: External USB disks not recognized with v6.1.8 when using Xen
Date: Mon, 6 Feb 2023 10:54:43 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1.1.1: Type: text/plain, Size: 1822 bytes --]

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?


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

  reply	other threads:[~2023-02-06  9:55 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-30  3:46 External USB disks not recognized with v6.1.8 when using Xen Christian Kujau
2023-01-30  5:17 ` Greg KH
2023-01-30 12:01 ` Linux kernel regression tracking (#adding)
2023-01-31 22:50   ` Christian Kujau
2023-02-01  8:14     ` Juergen Gross
2023-02-01  9:37       ` Christian Kujau
2023-02-02 11:38       ` Christian Kujau
2023-02-02 20:24         ` Linus Torvalds
2023-02-03 16:50           ` Christian Kujau
2023-02-03 17:29             ` Christian Kujau
2023-02-05 13:20           ` Borislav Petkov
2023-02-05 17:17             ` Christian Kujau
2023-02-05 20:21             ` Linus Torvalds
2023-02-06  6:33               ` Juergen Gross
2023-02-06  9:54                 ` Juergen Gross [this message]
2023-02-06  9:43               ` Borislav Petkov
2023-02-05 10:40     ` Linux kernel regression tracking (#update)
2023-02-14  9:35 ` [tip: x86/urgent] x86/mtrr: Revert 90b926e68f50 ("x86/pat: Fix pat_x_mtrr_type() for MTRR disabled case") tip-bot2 for Juergen Gross
2023-02-18  9:47   ` Christian Kujau
2023-02-18  9:59     ` Borislav Petkov
2023-05-08 13:41     ` [tip: x86/cleanups] Documentation/process: Explain when tip branches get merged into mainline tip-bot2 for Christian Kujau
2023-05-15 15:28     ` tip-bot2 for Christian Kujau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).