All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Oleksii Kurochko" <oleksii.kurochko@gmail.com>
Subject: [PATCH v2 for-4.20 2/6] x86/PCI: init segments earlier
Date: Mon, 3 Feb 2025 17:24:39 +0100	[thread overview]
Message-ID: <fc207c1d-80ae-49fb-96e0-ffa335510044@suse.com> (raw)
In-Reply-To: <30f29dde-15e1-4af9-b86f-0040658c381a@suse.com>

In order for amd_iommu_detect_one_acpi()'s call to pci_ro_device() to
have permanent effect, pci_segments_init() needs to be called ahead of
making it there. Without this we're losing segment 0's r/o map, and thus
we're losing write-protection of the PCI devices representing IOMMUs.
Which in turn means that half-way recent Linux Dom0 will, as it boots,
turn off MSI on these devices, thus preventing any IOMMU events (faults
in particular) from being reported on pre-x2APIC hardware.

As the acpi_iommu_init() invocation was moved ahead of
acpi_mmcfg_init()'s by the offending commit, move the call to
pci_segments_init() accordingly.

Fixes: 3950f2485bbc ("x86/x2APIC: defer probe until after IOMMU ACPI table parsing")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Tested-by: Jason Andryuk <jason.andryuk@amd.com>
---
Of course it would have been quite a bit easier to notice this issue if
radix_tree_insert() wouldn't work fine ahead of radix_tree_init() being
invoked for a given radix tree, when the index inserted at is 0.

While hunting down various other dead paths to actually find the root
cause, it occurred to me that it's probably not a good idea to fully
disallow config space writes for r/o devices: Dom0 won't be able to size
their BARs (luckily the IOMMU "devices" don't have any, but e.g. serial
ones generally will have at least one), for example. Without being able
to size BARs it also will likely be unable to correctly account for the
address space taken by these BARs. However, outside of vPCI it's not
really clear to me how we could reasonably emulate such BAR sizing
writes - we can't, after all, allow Dom0 to actually write to the
underlying physical registers, yet we don't intercept reads (i.e. we
can't mimic expected behavior then).

--- a/xen/arch/x86/x86_64/mmconfig-shared.c
+++ b/xen/arch/x86/x86_64/mmconfig-shared.c
@@ -402,8 +402,6 @@ void __init acpi_mmcfg_init(void)
 {
     bool valid = true;
 
-    pci_segments_init();
-
     /* MMCONFIG disabled */
     if ((pci_probe & PCI_PROBE_MMCONF) == 0)
         return;
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -55,6 +55,8 @@ void __init acpi_iommu_init(void)
 {
     int ret = -ENODEV;
 
+    pci_segments_init();
+
     if ( !iommu_enable && !iommu_intremap )
         return;
 



  parent reply	other threads:[~2025-02-03 16:24 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-03 16:22 [PATCH for-4.20 0/6] AMD/IOMMU: assorted corrections Jan Beulich
2025-02-03 16:24 ` [PATCH v2 for-4.20? 1/6] AMD/IOMMU: drop stray MSI enabling Jan Beulich
2025-02-03 16:54   ` Roger Pau Monné
2025-02-03 16:24 ` Jan Beulich [this message]
2025-02-03 16:25 ` [PATCH v2 for-4.20 3/6] radix-tree: purge node allocation override hooks Jan Beulich
2025-02-03 16:29   ` Jan Beulich
2025-02-03 16:36   ` Andrew Cooper
2025-02-03 16:25 ` [PATCH v2 for-4.21 4/6] radix-tree: drop "root" parameters from radix_tree_node_{alloc,free}() Jan Beulich
2025-02-03 16:40   ` Andrew Cooper
2025-02-03 16:26 ` [PATCH v2 for-4.20? 5/6] radix-tree: introduce RADIX_TREE{,_INIT}() Jan Beulich
2025-02-03 16:48   ` Andrew Cooper
2025-02-03 16:58     ` Jan Beulich
2025-02-04  8:36       ` Jan Beulich
2025-02-04  8:45         ` Jan Beulich
2025-02-04 11:19         ` Andrew Cooper
2025-02-03 16:27 ` [PATCH v2 for-4.20? 6/6] PCI: drop pci_segments_init() Jan Beulich
2025-02-03 17:04   ` Andrew Cooper
2025-02-04  7:17     ` Jan Beulich
2025-02-03 17:18   ` Roger Pau Monné
2025-02-04  7:45     ` Jan Beulich
2025-02-04  7:51       ` Jan Beulich
2025-02-04  8:56         ` Roger Pau Monné
2025-02-04  9:53           ` Jan Beulich
2025-02-03 16:38 ` [PATCH for-4.20 0/6] AMD/IOMMU: assorted corrections Oleksii Kurochko
2025-02-03 16:55   ` Andrew Cooper
2025-02-04  7:14   ` Jan Beulich

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=fc207c1d-80ae-49fb-96e0-ffa335510044@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=oleksii.kurochko@gmail.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.