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>,
	Brian Woods <brian.woods@amd.com>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Subject: [Xen-devel] [PATCH v3 05/14] AMD/IOMMU: pass IOMMU to iterate_ivrs_entries() callback
Date: Tue, 16 Jul 2019 16:37:04 +0000	[thread overview]
Message-ID: <e2072315-7c8c-2f82-99f4-795cc93f1fa8@suse.com> (raw)
In-Reply-To: <6272c301-a905-38cf-dd1a-645f3d703241@suse.com>

Both users will want to know IOMMU properties (specifically the IRTE
size) subsequently. Leverage this to avoid pointless calls to the
callback when IVRS mapping table entries are unpopulated. To avoid
leaking interrupt remapping tables (bogusly) allocated for IOMMUs
themselves, this requires suppressing their allocation in the first
place, taking a step further what commit 757122c0cf ('AMD/IOMMU: don't
"add" IOMMUs') had done.

Additionally suppress the call for alias entries, as again both users
don't care about these anyway. In fact this eliminates a fair bit of
redundancy from dump output.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v3: New.
---
TBD: Along the lines of avoiding the IRT allocation for the IOMMUs, is
      there a way to recognize the many CPU-provided devices many of
      which can't generate interrupts anyway, and avoid allocations for
      them as well? It's 32k per device, after all. Another option might
      be on-demand allocation of the tables, but quite possibly we'd get
      into trouble with error handling there.

--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -65,7 +65,11 @@ static void __init add_ivrs_mapping_entr
      /* override flags for range of devices */
      ivrs_mappings[bdf].device_flags = flags;
  
-    if (ivrs_mappings[alias_id].intremap_table == NULL )
+    /* Don't map an IOMMU by itself. */
+    if ( iommu->bdf == bdf )
+        return;
+
+    if ( !ivrs_mappings[alias_id].intremap_table )
      {
           /* allocate per-device interrupt remapping table */
           if ( amd_iommu_perdev_intremap )
@@ -81,8 +85,9 @@ static void __init add_ivrs_mapping_entr
               ivrs_mappings[alias_id].intremap_inuse = shared_intremap_inuse;
           }
      }
-    /* Assign IOMMU hardware, but don't map an IOMMU by itself. */
-    ivrs_mappings[bdf].iommu = iommu->bdf != bdf ? iommu : NULL;
+
+    /* Assign IOMMU hardware. */
+    ivrs_mappings[bdf].iommu = iommu;
  }
  
  static struct amd_iommu * __init find_iommu_from_bdf_cap(
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -1069,7 +1069,8 @@ int iterate_ivrs_mappings(int (*handler)
      return rc;
  }
  
-int iterate_ivrs_entries(int (*handler)(u16 seg, struct ivrs_mappings *))
+int iterate_ivrs_entries(int (*handler)(const struct amd_iommu *,
+                                        struct ivrs_mappings *))
  {
      u16 seg = 0;
      int rc = 0;
@@ -1082,7 +1083,12 @@ int iterate_ivrs_entries(int (*handler)(
              break;
          seg = IVRS_MAPPINGS_SEG(map);
          for ( bdf = 0; !rc && bdf < ivrs_bdf_entries; ++bdf )
-            rc = handler(seg, map + bdf);
+        {
+            const struct amd_iommu *iommu = map[bdf].iommu;
+
+            if ( iommu && map[bdf].dte_requestor_id == bdf )
+                rc = handler(iommu, &map[bdf]);
+        }
      } while ( !rc && ++seg );
  
      return rc;
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -617,7 +617,7 @@ void amd_iommu_read_msi_from_ire(
  }
  
  int __init amd_iommu_free_intremap_table(
-    u16 seg, struct ivrs_mappings *ivrs_mapping)
+    const struct amd_iommu *iommu, struct ivrs_mappings *ivrs_mapping)
  {
      void *tb = ivrs_mapping->intremap_table;
  
@@ -693,14 +693,15 @@ static void dump_intremap_table(const u3
      }
  }
  
-static int dump_intremap_mapping(u16 seg, struct ivrs_mappings *ivrs_mapping)
+static int dump_intremap_mapping(const struct amd_iommu *iommu,
+                                 struct ivrs_mappings *ivrs_mapping)
  {
      unsigned long flags;
  
      if ( !ivrs_mapping )
          return 0;
  
-    printk("  %04x:%02x:%02x:%u:\n", seg,
+    printk("  %04x:%02x:%02x:%u:\n", iommu->seg,
             PCI_BUS(ivrs_mapping->dte_requestor_id),
             PCI_SLOT(ivrs_mapping->dte_requestor_id),
             PCI_FUNC(ivrs_mapping->dte_requestor_id));
--- a/xen/include/asm-x86/amd-iommu.h
+++ b/xen/include/asm-x86/amd-iommu.h
@@ -129,7 +129,8 @@ extern u8 ivhd_type;
  
  struct ivrs_mappings *get_ivrs_mappings(u16 seg);
  int iterate_ivrs_mappings(int (*)(u16 seg, struct ivrs_mappings *));
-int iterate_ivrs_entries(int (*)(u16 seg, struct ivrs_mappings *));
+int iterate_ivrs_entries(int (*)(const struct amd_iommu *,
+                                 struct ivrs_mappings *));
  
  /* iommu tables in guest space */
  struct mmio_reg {
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
@@ -98,7 +98,8 @@ struct amd_iommu *find_iommu_for_device(
  /* interrupt remapping */
  int amd_iommu_setup_ioapic_remapping(void);
  void *amd_iommu_alloc_intremap_table(unsigned long **);
-int amd_iommu_free_intremap_table(u16 seg, struct ivrs_mappings *);
+int amd_iommu_free_intremap_table(
+    const struct amd_iommu *, struct ivrs_mappings *);
  void amd_iommu_ioapic_update_ire(
      unsigned int apic, unsigned int reg, unsigned int value);
  unsigned int amd_iommu_read_ioapic_from_ire(

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  parent reply	other threads:[~2019-07-16 16:38 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-16 16:30 [Xen-devel] [PATCH v3 00/14] x86: AMD x2APIC support Jan Beulich
2019-07-16 16:35 ` [Xen-devel] [PATCH v3 01/14] AMD/IOMMU: free more memory when cleaning up after error Jan Beulich
2019-07-19 15:02   ` Andrew Cooper
2019-07-19 18:22   ` Woods, Brian
2019-07-16 16:35 ` [Xen-devel] [PATCH v3 02/14] AMD/IOMMU: use bit field for extended feature register Jan Beulich
2019-07-17  6:19   ` Jan Beulich
2019-07-19 16:23   ` Andrew Cooper
2019-07-19 16:27     ` Jan Beulich
2019-07-16 16:36 ` [Xen-devel] [PATCH v3 03/14] AMD/IOMMU: use bit field for control register Jan Beulich
2019-07-19 18:23   ` Woods, Brian
2019-07-22  8:55     ` Jan Beulich
2019-07-16 16:36 ` [Xen-devel] [PATCH v3 04/14] AMD/IOMMU: use bit field for IRTE Jan Beulich
2019-07-19 15:56   ` Andrew Cooper
2019-07-19 16:16     ` Jan Beulich
2019-07-19 18:44       ` Andrew Cooper
2019-07-22 12:50         ` Jan Beulich
2019-07-19 18:24   ` Woods, Brian
2019-07-16 16:37 ` Jan Beulich [this message]
2019-07-19 16:32   ` [Xen-devel] [PATCH v3 05/14] AMD/IOMMU: pass IOMMU to iterate_ivrs_entries() callback Andrew Cooper
2019-07-19 18:26   ` Woods, Brian
2019-07-16 16:37 ` [Xen-devel] [PATCH v3 06/14] AMD/IOMMU: pass IOMMU to amd_iommu_alloc_intremap_table() Jan Beulich
2019-07-19 16:34   ` Andrew Cooper
2019-07-19 18:27   ` Woods, Brian
2019-07-16 16:37 ` [Xen-devel] [PATCH v3 07/14] AMD/IOMMU: pass IOMMU to {get, free, update}_intremap_entry() Jan Beulich
2019-07-19 16:47   ` Andrew Cooper
2019-07-19 18:32   ` Woods, Brian
2019-07-16 16:38 ` [Xen-devel] [PATCH v3 08/14] AMD/IOMMU: introduce 128-bit IRTE non-guest-APIC IRTE format Jan Beulich
2019-07-19 17:27   ` Andrew Cooper
2019-07-22  8:34     ` Jan Beulich
2019-07-22 13:36       ` Andrew Cooper
2019-07-22 15:01         ` Jan Beulich
2019-07-22 15:43           ` Andrew Cooper
2019-07-23  8:13             ` Jan Beulich
2019-07-23  8:19               ` Jan Beulich
2019-07-16 16:39 ` [Xen-devel] [PATCH v3 09/14] AMD/IOMMU: split amd_iommu_init_one() Jan Beulich
2019-07-19 18:36   ` Woods, Brian
2019-07-16 16:39 ` [Xen-devel] [PATCH v3 10/14] AMD/IOMMU: allow enabling with IRQ not yet set up Jan Beulich
2019-07-19 18:38   ` Woods, Brian
2019-07-16 16:39 ` [Xen-devel] [PATCH v3 11/14] AMD/IOMMU: adjust setup of internal interrupt for x2APIC mode Jan Beulich
2019-07-19 17:31   ` Andrew Cooper
2019-07-22  8:43     ` Jan Beulich
2019-07-22 13:45       ` Andrew Cooper
2019-07-22 15:22         ` Jan Beulich
2019-07-19 18:39   ` Woods, Brian
2019-07-16 16:40 ` [Xen-devel] [PATCH v3 12/14] AMD/IOMMU: enable x2APIC mode when available Jan Beulich
2019-07-19 17:38   ` Andrew Cooper
2019-07-19 18:41   ` Woods, Brian
2019-07-16 16:40 ` [Xen-devel] [PATCH RFC v3 13/14] AMD/IOMMU: correct IRTE updating Jan Beulich
2019-07-19 17:44   ` Andrew Cooper
2019-07-16 16:41 ` [Xen-devel] [PATCH v3 14/14] AMD/IOMMU: process softirqs while dumping IRTs Jan Beulich
2019-07-19 17:55   ` Andrew Cooper
2019-07-22  8:49     ` Jan Beulich
2019-07-22 12:17       ` Andrew Cooper
2019-07-19 18:43   ` Woods, Brian

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=e2072315-7c8c-2f82-99f4-795cc93f1fa8@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=brian.woods@amd.com \
    --cc=suravee.suthikulpanit@amd.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.