From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE2E9D1AD55 for ; Wed, 16 Oct 2024 13:26:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 49F7F6B0082; Wed, 16 Oct 2024 09:26:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 44F126B0083; Wed, 16 Oct 2024 09:26:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3167F6B008C; Wed, 16 Oct 2024 09:26:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0F0616B0082 for ; Wed, 16 Oct 2024 09:26:17 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 877D8140388 for ; Wed, 16 Oct 2024 13:26:06 +0000 (UTC) X-FDA: 82679538942.05.3B67305 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by imf09.hostedemail.com (Postfix) with ESMTP id 7DC66140020 for ; Wed, 16 Oct 2024 13:26:08 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=T1LeTC8I; spf=pass (imf09.hostedemail.com: domain of jannh@google.com designates 209.85.208.44 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729085031; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=O7EgR5OSjoWSs3q+41nfNzDZd6mbVvdVr2357ZxksYQ=; b=wzUPz/0OP3Gz/H97UigN8oaEXFv1Ggg7QLhyDGbN7TK5wHMslLdDxyL5H+JZtNWJqoya04 V2l7Hn6pEM+LL0UprdQzmf+9Iv5ZET+ogRPdo3vvJPejHEm3jci9thTnAzifq+hm0H7e/z n+bechFhAQmnu3AK40m2CqDfJ6SOe7Y= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729085031; a=rsa-sha256; cv=none; b=pbxPPLLbgklvR9M9gdp3P+Q2aJE+OYL+KBJo9cr8/ljG/ooQQupWFE0i5CwIQviUcQJ1Bg EHYHOqvo3ZOVX/OmUiXIE6p7/LdLlVh/7Heon3jWTZZSJnV3ohRsX4cfAuzuprR6oF7jrE cw+vJGdpNe/UdnqZWVdh5sI+DR4ph04= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=T1LeTC8I; spf=pass (imf09.hostedemail.com: domain of jannh@google.com designates 209.85.208.44 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-5c93e9e701fso13545a12.1 for ; Wed, 16 Oct 2024 06:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1729085173; x=1729689973; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=O7EgR5OSjoWSs3q+41nfNzDZd6mbVvdVr2357ZxksYQ=; b=T1LeTC8IqUZzTdw5wIQm38/dTxgGezSqQlSWNmCtKQARTPfBXS+mQN1BZ4xS+/2a+m E2TW6Q4qITSW5V7vaSUEB3vqI+z9Ck7yGmN1q+YESGNzMD9sMKAkP5RQAIlan8YXHmW9 w1xj3g4tRiomtYUAZJFUawNlRnJfg8gVrstVBeIUcSVXX9XgfKPNeTZMoPz3LtIrR27h Ao7WVK3wAjJUklhxg8RKN1gerRIgrZdciO/vLQllp8WrwjBe0meozjc6Yat+GGzWqgH+ ofkICh4hrQxWtzSjH37xenWKlsKeHII8Md1U1xjw2X5oBxpFZAPkBIVc9oAyGV4FGI9l AEmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729085173; x=1729689973; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=O7EgR5OSjoWSs3q+41nfNzDZd6mbVvdVr2357ZxksYQ=; b=gvVVRTeazM5LMNelhblb1RBXzYUyWGDgOFU9VdBm+/A1UR25KKx7r2RdXcX9UPfIC6 Jvhg5SQzvBp3P4yzM83COcPidH2GUKICk4FQQssgHlFFS/rhIhXhIRomuwMo07MCy4oy SHrXVYuR0TW8J/0vvNEXhcT0fHFY1l/4q+RNxxsW69MpgaSdzKlwreseESGbE1EM7NN4 cLrU8bbgFHDHfu36ar8FKmJ63K337hRKs08HfqG+sDl5qw7ZpZKa/nqfBz70cb+KUqVc WFtaHxgt6yK+wwmmnBiZU/vEaff5HpOWeRalenTTkYBwTHie427WdK5/jdrsIVrvWQ/j hqkg== X-Forwarded-Encrypted: i=1; AJvYcCV3OwqOIWrP3aQ8n44d32wPeFi9puF5AEifZL+hbDJiT6OSl7pyX2mEQgIs46Pz3i+d/kqevl0fSg==@kvack.org X-Gm-Message-State: AOJu0YyhEIQaZ06FtcvanYPxRamfQEqAk2JxURRMjyCVkFPSznRPfU2m 2v2JanIfpyWGlB2CAOi0jWkng8G7H7fk1SNFJuhRUY41ze2M28pYZvop522AmViJHA5BhiW3U4/ rnh+cTYr254UUbJgJg313u6izb9yhZFd80WYT X-Google-Smtp-Source: AGHT+IHm4uAnm6x4gqyE8JxaDYdv12A+djBdgtqoCDD2tCHeA1XFE3cLD3QA0GXWVVrvkSNF4Qk2pPtyOLiHFomBKfc= X-Received: by 2002:a05:6402:234a:b0:5c8:a0fd:64f0 with SMTP id 4fb4d7f45d1cf-5c9979d0b81mr492682a12.2.1729085172800; Wed, 16 Oct 2024 06:26:12 -0700 (PDT) MIME-Version: 1.0 References: <20240903232241.43995-1-anthony.yznaga@oracle.com> In-Reply-To: From: Jann Horn Date: Wed, 16 Oct 2024 15:25:34 +0200 Message-ID: Subject: Re: [RFC PATCH v3 00/10] Add support for shared PTEs across processes To: Anthony Yznaga Cc: akpm@linux-foundation.org, willy@infradead.org, markhemm@googlemail.com, viro@zeniv.linux.org.uk, david@redhat.com, khalid@kernel.org, andreyknvl@gmail.com, dave.hansen@intel.com, luto@kernel.org, brauner@kernel.org, arnd@arndb.de, ebiederm@xmission.com, catalin.marinas@arm.com, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhiramat@kernel.org, rostedt@goodmis.org, vasily.averin@linux.dev, xhao@linux.alibaba.com, pcc@google.com, neilb@suse.de, maz@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 7DC66140020 X-Stat-Signature: u85xbz1fftehrcc4cp9wy4rq4pmsedkr X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1729085168-908766 X-HE-Meta: U2FsdGVkX186cm/wPNGys6WEMzRWVg3rwstkveZe+aa7iAjgOCV1U49AEsgPqyQTvM4jt/K0r0Kpv1QD8VCz5TTmgTCLuAkbbfNk2sY2HMBYNdc2S9AGMRz9VCbQHmLNDYRQfIs4/gqkN7tgN+/eKn9M4hjObbHZZSiHn2L8wRMV6dvJQPGUD7Iv2F1WtuWM5dVU9eU6cU/5IfnZ38KEoxhwWiFmPq2SA2008ReRKz8vnT2ZPUsMy+g/JZ7Rgj+RvZus2gzsO8G93iJLJpfbWlzceeZ9uyrpba3wJPbidgDOp7nuNrWmp7z3BQWHFpv8eXgJYlXyDapYADECD55/2QaJ1jBA600rfJNSJxo9hWown8taftC38u7qo/iUK+c+VuqLgdWE+ktrckCIvI700PypQlmQTJlkpLLA9EkAZqwlpImEN+1eozvUYEU2s2SB/nMPm/Vd8tHLMXIQ/ysqPrbtUsUnKUpCX+FCn4ZLMDkGObDch/ExvVj35vMtmis2NfX/BPT73kLGc/wW1SIX+BkpI0bi2lC8/nEgs70qUemtlYcw9JInXtgnzKkNevSLbE/77ZtIkl8+h6jg/onPFX78ZP6trfi24CE5unJ4gklVEucNXWcbvfZMlLFSJub/56s1b/CflnY3LRfUB/ig688jH+en9PNtgFMYkuyxYifTtqVbX4zKydngI4r86yiU0maQgNJ9RdicSuOE+ngeMDhROBFr/P5SBPpMoMIOahi3gclUtnyWFxFJCNES7sEDv++enBAgUQ38eLmKf1fQ4F/rpWzwYLNjvOSPZItRvxAo26u8Kcn2h1Sdb6GaPJ+t7q1OM0/+wzraq102HrDWCQRc/ob6cboV76NhuLAWVDpGS08pYAAeve+DURcvRYSshM9isES7Q7d/jGzcnzZXH1sw47yIH3hlm5MNjv6WuddXXWwtnEvT+YUSDZnSALbLQaW4nsDAakZ2lJhO6gb LmqSZQxa /sCVh+XYIhAbeAJCSo0Z4M4y4sNTu9yqIrUxdgqsacgkROwVFLJlCP7lnWGfHMoIzOvdXnNkrt58LpUjXPuIGB6TzwUVQW2GBtpqsKdH+kfgvmzFCG9kTXJ9TqkWeyLyyBGsIbBvelldh7WuQK9PJ1ATmjIKpYVh2Rh86f57oB9F2KqgjQZ1wIsoO6cecmHQs6jJAxk2exc0gR7iuxSg7Q+tTja2eoSPqEswyJI8txkxDYO6RPhmHOTOHw+1bbaE2O+V2528ljTcQ1Gk= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Oct 16, 2024 at 2:59=E2=80=AFAM Anthony Yznaga wrote: > On 10/14/24 1:07 PM, Jann Horn wrote: > > Second, there is a newer mode for IOMMUv2 stuff (using the > > mmu_notifier_ops::invalidate_range callback), where the idea is that > > you have secondary MMUs that share the normal page tables, and so you > > basically send them invalidations at the same time you invalidate the > > primary MMU for the process. I think that's the right fit for this > > usecase; however, last I looked, this code was extremely broken (see > > https://lore.kernel.org/lkml/CAG48ez2NQKVbv=3DyG_fq_jtZjf8Q=3D+Wy54FxcF= rK_OujFg5BwSQ@mail.gmail.com/ > > for context). Unless that's changed in the meantime, I think someone > > would have to fix that code before it can be relied on for new > > usecases. > > Thank you for this background! Looks like there have since been some > changes to the mmu notifiers, and the invalidate_range callback became > arch_invalidate_secondary_tlbs. I'm currently looking into using it to > flush all TLBs. Ah, nice, that looks much better now. With the caveat that, from what I can tell, the notifiers only work on x86/arm64/powerpc - I guess maybe that infrastructure should be gated on a HAVE_... arch config flag...