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>, Paul Durrant <paul@xen.org>
Subject: [PATCH 00/17] IOMMU: superpage support when not sharing pagetables
Date: Tue, 24 Aug 2021 16:13:13 +0200	[thread overview]
Message-ID: <d955d9a3-33f6-f228-d007-a844ed918168@suse.com> (raw)

For a long time we've been rather inefficient with IOMMU page table
management when not sharing page tables, i.e. in particular for PV (and
further specifically also for PV Dom0) and AMD (where nowadays we never
share page tables). While up to about 2.5 years ago AMD code had logic
to un-shatter page mappings, that logic was ripped out for being buggy
(XSA-275 plus follow-on).

This series enables use of large pages in AMD and Intel (VT-d) code;
Arm is presently not in need of any enabling as pagetables are always
shared there. It also augments PV Dom0 creation with suitable explicit
IOMMU mapping calls to facilitate use of large pages there without
getting into the business of un-shattering page mappings just yet.
Depending on the amount of memory handed to Dom0 this improves booting
time (latency until Dom0 actually starts) quite a bit; subsequent
shattering of some of the large pages may of course consume some of the
saved time.

Parts of this series functionally depend on the previously submitted
"VT-d: fix caching mode IOTLB flushing".

Known fallout has been spelled out here:
https://lists.xen.org/archives/html/xen-devel/2021-08/msg00781.html

I'm inclined to say "of course" there are also various seemingly
unrelated changes included here, which I just came to consider necessary
or at least desirable (in part for having been in need of adjustment for
a long time) along the way. Some of these changes are likely independent
of the bulk of the work here, and hence may be fine to go in ahead of
earlier patches.

While, as said above, un-shattering of mappings isn't an immediate goal,
I intend to at least arrange for freeing page tables which have ended up
all empty. But that's not part of this v1 of the series.

01: AMD/IOMMU: avoid recording each level's MFN when walking page table
02: AMD/IOMMU: have callers specify the target level for page table walks
03: VT-d: have callers specify the target level for page table walks
04: IOMMU: have vendor code announce supported page sizes
05: IOMMU: add order parameter to ->{,un}map_page() hooks
06: IOMMU: have iommu_{,un}map() split requests into largest possible chunks
07: IOMMU/x86: restrict IO-APIC mappings for PV Dom0
08: IOMMU/x86: perform PV Dom0 mappings in batches
09: IOMMU/x86: support freeing of pagetables
10: AMD/IOMMU: drop stray TLB flush
11: AMD/IOMMU: walk trees upon page fault
12: AMD/IOMMU: return old PTE from {set,clear}_iommu_pte_present()
13: AMD/IOMMU: allow use of superpage mappings
14: VT-d: allow use of superpage mappings
15: IOMMU: page table dumping adjustments
16: VT-d: show permissions during page table walks
17: IOMMU/x86: drop pointless NULL checks

While not directly related (except that making this mode work properly
here was a fair part of the overall work), at this occasion I'd also
like to renew my proposal to make "iommu=dom0-strict" the default going
forward. It already is not only the default, but the only possible mode
for PVH Dom0.

Jan



             reply	other threads:[~2021-08-24 14:13 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-24 14:13 Jan Beulich [this message]
2021-08-24 14:15 ` [PATCH 01/17] AMD/IOMMU: avoid recording each level's MFN when walking page table Jan Beulich
2021-08-25 13:29   ` Andrew Cooper
2021-08-24 14:15 ` [PATCH 02/17] AMD/IOMMU: have callers specify the target level for page table walks Jan Beulich
2021-08-24 14:16 ` [PATCH 03/17] VT-d: " Jan Beulich
2021-08-24 14:17 ` [PATCH 04/17] IOMMU: have vendor code announce supported page sizes Jan Beulich
2021-09-16  7:38   ` Tian, Kevin
2021-08-24 14:18 ` [PATCH 05/17] IOMMU: add order parameter to ->{,un}map_page() hooks Jan Beulich
2021-09-16  7:41   ` Tian, Kevin
2021-08-24 14:19 ` [PATCH 06/17] IOMMU: have iommu_{,un}map() split requests into largest possible chunks Jan Beulich
2021-08-24 14:21 ` [PATCH 07/17] IOMMU/x86: restrict IO-APIC mappings for PV Dom0 Jan Beulich
2021-08-26 11:57   ` Andrew Cooper
2021-08-26 12:55     ` Jan Beulich
2021-09-07 17:13       ` Andrew Cooper
2021-09-08  9:44         ` Jan Beulich
2021-08-24 14:21 ` [PATCH 08/17] IOMMU/x86: perform PV Dom0 mappings in batches Jan Beulich
2021-08-24 14:22 ` [PATCH 09/17] IOMMU/x86: support freeing of pagetables Jan Beulich
2021-08-24 14:22 ` [PATCH 10/17] AMD/IOMMU: drop stray TLB flush Jan Beulich
2021-08-24 14:23 ` [PATCH 11/17] AMD/IOMMU: walk trees upon page fault Jan Beulich
2021-08-24 14:24 ` [PATCH 12/17] AMD/IOMMU: return old PTE from {set,clear}_iommu_pte_present() Jan Beulich
2021-08-24 14:25 ` [PATCH 13/17] AMD/IOMMU: allow use of superpage mappings Jan Beulich
2021-08-24 14:25 ` [PATCH 14/17] VT-d: " Jan Beulich
2021-08-24 14:26 ` [PATCH 15/17] IOMMU: page table dumping adjustments Jan Beulich
2021-08-24 14:28   ` Jan Beulich
2021-09-16  7:33     ` Tian, Kevin
2021-08-24 14:27 ` [PATCH 16/17] VT-d: show permissions during page table walks Jan Beulich
2021-09-16  7:36   ` Tian, Kevin
2021-08-24 14:27 ` [PATCH 17/17] IOMMU/x86: drop pointless NULL checks Jan Beulich
2021-08-26 12:05   ` Andrew Cooper
2021-08-26 12:36     ` Jan Beulich
2021-09-15 12:42   ` Ping: " Jan Beulich
2021-09-16  7:47     ` Tian, Kevin
2021-09-16  8:24       ` Jan Beulich
2021-09-16  7:29   ` Tian, Kevin
2021-08-25 12:06 ` [PATCH 00/17] IOMMU: superpage support when not sharing pagetables 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=d955d9a3-33f6-f228-d007-a844ed918168@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=paul@xen.org \
    --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.