[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH v7 00/14] IOMMU: superpage support when not sharing pagetables


  • To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 5 Jul 2022 14:41:42 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SZgNX/Ze/9TuUARcqgxwlervi79kuR7lK9LTAC8e/6E=; b=Dp0JpIWeH1ZrVIrw9tJdc6ttcsl26637yVXi6YlaLBJlSOfqQAtijCsdOlReaE7ZXnB2b0frXnatKgHB4J1wwQ3Br31i5eHinfCC7taIZAXz4zV67GZZ3s9Qvn5uZR4fETy2ZUhiXqVvNTj4xI0FdLk/p2dOsHDJV0WoL0d9fpBU58jb/Jj0QDdaDeQeOAQETJGVT2teOpcYA/cv95tuvTIXLxOdXZELWC4JygAOH+Y7y1oT5AUCwf1USPg2+39OVnZlmhQkbQxrr4NIXCQTUUCfIqmvarZd2zqdERFzkTDvRL5rcKWq4o6KKIZoLz+AJ+q8TI1lDQ1TVmZqeQ9KDg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kW430Gk2YoxrYANo+bhtELxsYYWIpXOrauMdAocVVvCNtDNE/MsF46uUb5ojNafuxyrIOx/eXUjlUUeghziTt7Ex7rpbu1LHyWB8RWEW128T4+aXN6MkAIin8ml8GWs4E/XP1RwYzUMO3sHoWnp1NNOv3lwUbAqHBtfrlfYLx6X329vgmvcOvg/DOxd62eghOBreu8ECs1usy8/EMZOT5gzmRinB/boJFYPj4d6X4fkCSmk2/Er1//MCrkVKftEACFCYbtXiswSCutdJ27IRxw5DxnhDLsOAiDFoK2tm+lTBqAMhs+6jbxT3wih+7lq0Q+pJPPiOTY/VtrsE5z5YFA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Tue, 05 Jul 2022 12:41:56 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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 3.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. 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.

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

See individual patches for details on the v7 changes.

01: iommu: add preemption support to iommu_{un,}map()
02: IOMMU/x86: perform PV Dom0 mappings in batches
03: IOMMU/x86: support freeing of pagetables
02: IOMMU/x86: new command line option to suppress use of superpage mappings
03: AMD/IOMMU: allow use of superpage mappings
04: VT-d: allow use of superpage mappings
05: x86: introduce helper for recording degree of contiguity in page tables
06: IOMMU/x86: prefill newly allocate page tables
07: AMD/IOMMU: free all-empty page tables
08: VT-d: free all-empty page tables
09: AMD/IOMMU: replace all-contiguous page tables by superpage mappings
10: VT-d: replace all-contiguous page tables by superpage mappings
11: IOMMU/x86: add perf counters for page table splitting / coalescing
12: VT-d: fold dma_pte_clear_one() into its only caller

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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.