From: Peter Collingbourne <pcc@google.com>
To: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu
Cc: Peter Collingbourne <pcc@google.com>,
Cornelia Huck <cohuck@redhat.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
Evgenii Stepanov <eugenis@google.com>,
kvm@vger.kernel.org, Steven Price <steven.price@arm.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>
Subject: [PATCH v4 0/8] KVM: arm64: permit MAP_SHARED mappings with MTE enabled
Date: Tue, 20 Sep 2022 20:51:32 -0700 [thread overview]
Message-ID: <20220921035140.57513-1-pcc@google.com> (raw)
Hi,
This patch series allows VMMs to use shared mappings in MTE enabled
guests. The first five patches were taken from Catalin's tree [1] which
addressed some review feedback from when they were previously sent out
as v3 of this series. The first patch from Catalin's tree makes room
for an additional PG_arch_3 flag by making the newer PG_arch_* flags
arch-dependent. The next four patches are based on a series that
Catalin sent out prior to v3, whose cover letter [2] I quote from below:
> This series aims to fix the races between initialising the tags on a
> page and setting the PG_mte_tagged flag. Currently the flag is set
> either before or after that tag initialisation and this can lead to CoW
> copying stale tags. The first patch moves the flag setting after the
> tags have been initialised, solving the CoW issue. However, concurrent
> mprotect() on a shared mapping may (very rarely) lead to valid tags
> being zeroed.
>
> The second skips the sanitise_mte_tags() call in kvm_set_spte_gfn(),
> deferring it to user_mem_abort(). The outcome is that no
> sanitise_mte_tags() can be simplified to skip the pfn_to_online_page()
> check and only rely on VM_MTE_ALLOWED vma flag that can be checked in
> user_mem_abort().
>
> The third and fourth patches use PG_arch_3 as a lock for page tagging,
> based on Peter Collingbourne's idea of a two-bit lock.
>
> I think the first patch can be queued but the rest needs some in depth
> review and test. With this series (if correct) we could allos MAP_SHARED
> on KVM guest memory but this is to be discussed separately as there are
> some KVM ABI implications.
I rebased Catalin's tree onto -next and added the proposed userspace
enablement patches after the series. I've tested it on QEMU as well as
on MTE-capable hardware by booting a Linux kernel and userspace under
a crosvm with MTE support [3].
[1] git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux devel/mte-pg-flags
[2] https://lore.kernel.org/all/20220705142619.4135905-1-catalin.marinas@arm.com/
[3] https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3892141
Catalin Marinas (4):
mm: Do not enable PG_arch_2 for all 64-bit architectures
arm64: mte: Fix/clarify the PG_mte_tagged semantics
KVM: arm64: Simplify the sanitise_mte_tags() logic
arm64: mte: Lock a page for MTE tag initialisation
Peter Collingbourne (4):
mm: Add PG_arch_3 page flag
KVM: arm64: unify the tests for VMAs in memslots when MTE is enabled
KVM: arm64: permit all VM_MTE_ALLOWED mappings with MTE enabled
Documentation: document the ABI changes for KVM_CAP_ARM_MTE
Documentation/virt/kvm/api.rst | 5 ++-
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/mte.h | 65 ++++++++++++++++++++++++++++++-
arch/arm64/include/asm/pgtable.h | 4 +-
arch/arm64/kernel/cpufeature.c | 4 +-
arch/arm64/kernel/elfcore.c | 2 +-
arch/arm64/kernel/hibernate.c | 2 +-
arch/arm64/kernel/mte.c | 16 ++++----
arch/arm64/kvm/guest.c | 18 +++++----
arch/arm64/kvm/mmu.c | 55 +++++++++++---------------
arch/arm64/mm/copypage.c | 7 +++-
arch/arm64/mm/fault.c | 4 +-
arch/arm64/mm/mteswap.c | 13 ++++---
fs/proc/page.c | 3 +-
include/linux/kernel-page-flags.h | 1 +
include/linux/page-flags.h | 3 +-
include/trace/events/mmflags.h | 9 +++--
mm/Kconfig | 8 ++++
mm/huge_memory.c | 3 +-
19 files changed, 152 insertions(+), 71 deletions(-)
--
2.37.3.968.ga6b4b080e4-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2022-09-21 3:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-21 3:51 Peter Collingbourne [this message]
2022-09-21 3:51 ` [PATCH v4 1/8] mm: Do not enable PG_arch_2 for all 64-bit architectures Peter Collingbourne
2022-09-21 9:17 ` Steven Price
2022-09-21 3:51 ` [PATCH v4 2/8] arm64: mte: Fix/clarify the PG_mte_tagged semantics Peter Collingbourne
2022-09-21 3:51 ` [PATCH v4 3/8] KVM: arm64: Simplify the sanitise_mte_tags() logic Peter Collingbourne
2022-09-21 3:51 ` [PATCH v4 4/8] mm: Add PG_arch_3 page flag Peter Collingbourne
2022-09-21 9:17 ` Steven Price
2022-09-21 3:51 ` [PATCH v4 5/8] arm64: mte: Lock a page for MTE tag initialisation Peter Collingbourne
2022-09-21 3:51 ` [PATCH v4 6/8] KVM: arm64: unify the tests for VMAs in memslots when MTE is enabled Peter Collingbourne
2022-09-21 3:51 ` [PATCH v4 7/8] KVM: arm64: permit all VM_MTE_ALLOWED mappings with MTE enabled Peter Collingbourne
2022-09-21 3:51 ` [PATCH v4 8/8] Documentation: document the ABI changes for KVM_CAP_ARM_MTE Peter Collingbourne
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=20220921035140.57513-1-pcc@google.com \
--to=pcc@google.com \
--cc=catalin.marinas@arm.com \
--cc=cohuck@redhat.com \
--cc=eugenis@google.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=steven.price@arm.com \
--cc=vincenzo.frascino@arm.com \
--cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).