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

Re: [PATCH 00/17] IOMMU: superpage support when not sharing pagetables

  • To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 25 Aug 2021 14:06:48 +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-SenderADCheck; bh=wMCAVBZOF1ODtKLGj/2uF9N8WOvqW5qxcorizvqLzug=; b=K62YYrPOSY7eUIGwpd4G7UsOSNyMjImOmCWMCqW6x+IHJCGZBD6pAIRzLnmUrxTyUdm9F6mlThoo7ElV6m2RGHEKqu2g5m/Hkp6QP6aXrRVdBvWaZVaJ5CIE8p3yhz5Jt0whr3rvHxJNDRNhhVdmTEvm3m6CJqJ8x/gxvS+BKSQxX3N43rW4nKmxq1zE2DzfNzEGrUtP+9fFL/YjJtcO/G6w+fHUVTzgQoURek/F6mSz/qNjIUjqodGjjO9oQGxdhZp1OZjvKAChlUHSkVa7rGxsO0qmx7JfoqZIyJkLI/xuQpSRaAj+Yoehk6BuVzczZkFO7I6yK4X4elOrBcFEtA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=brP0h+7LwmmlX7U29OL+KWg3eZSThKS01jByY1RwkB6MJeUNmqvhnJqlksbN8TXs/TCpWemlInzVO/LSObILJXMeKLtBlvm/QTiHTMUKwi8Lm2YZ8IMzQK1BPYPXoZkGXJUl2xZCQAhKr8zxUsi+VHImi+86VBpBA75NxGiG9PaV/43KgyYejfobqBtPT1ZucUSJErrlAle5uJsRFZKVutq8AkkQ92Zg1v/RE/foFsxFudy2DCOI3rCGmyvH7sTerrBugzlW/gCf2KQizhdu8ol6CmTgKLa1ePN15AYJkW0e1zUHPCmGOnRKo1mS1yuAi1I2zaSkAYOQbJbRIKRtnQ==
  • Authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>
  • Delivery-date: Wed, 25 Aug 2021 12:07:10 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 24.08.2021 16:13, Jan Beulich wrote:
> 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

I should probably spell this out explicitly: These last two, which actually
enable use of superpages, and which hence introduce the need to shatter
some, comes with the risk of tripping code like this

        ret = xenmem_reservation_decrease(nr_pages, frame_list);
        BUG_ON(ret != nr_pages);

still found e.g. in up-to-date Linux. This is - similar to the other
fallout description pointed at further up - a result of now potentially
needing to allocate memory in order to free some, and perhaps the needed
amount being higher than the freed one.




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