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 D00D0EB64DC for ; Wed, 19 Jul 2023 03:04:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1B753280027; Tue, 18 Jul 2023 23:04:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1407D8D0012; Tue, 18 Jul 2023 23:04:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F2379280027; Tue, 18 Jul 2023 23:04:31 -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 DF8758D0012 for ; Tue, 18 Jul 2023 23:04:31 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BA70AAFFFB for ; Wed, 19 Jul 2023 03:04:31 +0000 (UTC) X-FDA: 81026868342.23.D5B2F94 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf08.hostedemail.com (Postfix) with ESMTP id 6ACD5160003 for ; Wed, 19 Jul 2023 03:04:29 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf08.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689735870; a=rsa-sha256; cv=none; b=a5mLAj42AU2nQIKMFy3LBKlakhDSYrW7ygENbmL1Om7fUH2HI5RRNMUDwcwFGhXPu7UHUQ OnszlWmWaONuCG/7lea99CR65aFpwbZkmC1nbOmSMqMUQDHyMnXvaDsYJHZKUrnSd/cU3n g4xW1mwrDz3kc66zEGmuN5jfEXVwqLQ= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf08.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689735870; 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; bh=P0s3BM+rzhOKR+BVZe/Xuz8wLGfC5tfcmO02Gl9DL6g=; b=W8+/JVkYC20lNp+Di78mY19rPL1YQQDkpwnA8AEgFFTh7cDdP17YwkN34l7c5DXSwibZBm rpIcM7NnvWQgld/Nkt6YcZuBoZiAhklw1r4yxE5nKV0rCQ+ZZ7NwJfm+4RVXO/wavOgcLv J0VJMoGTVWmXCPuQFUqFW2vbif0xivg= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 98A182F4; Tue, 18 Jul 2023 20:05:11 -0700 (PDT) Received: from [10.162.40.17] (unknown [10.162.40.17]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4BE363F67D; Tue, 18 Jul 2023 20:04:22 -0700 (PDT) Message-ID: <45fadf89-27ec-07a9-746a-e5d14aba62a3@arm.com> Date: Wed, 19 Jul 2023 08:34:19 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH 0/4] Invalidate secondary IOMMU TLB on permission upgrade Content-Language: en-US To: Alistair Popple , akpm@linux-foundation.org Cc: ajd@linux.ibm.com, catalin.marinas@arm.com, fbarrat@linux.ibm.com, iommu@lists.linux.dev, jgg@ziepe.ca, jhubbard@nvidia.com, kevin.tian@intel.com, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, mpe@ellerman.id.au, nicolinc@nvidia.com, npiggin@gmail.com, robin.murphy@arm.com, seanjc@google.com, will@kernel.org, x86@kernel.org, zhi.wang.linux@gmail.com References: From: Anshuman Khandual In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 6ACD5160003 X-Stat-Signature: 1d5e61f4yabnod4kf7chsfs6t5nkxbn5 X-Rspam-User: X-HE-Tag: 1689735869-51517 X-HE-Meta: U2FsdGVkX1+Cl9wSjUx/xDELahQeeJCGKX5bIIUrnpjl4JuvlBItnemx9BLbE80vR9mTXjJPohnAa8Nm2rkWhLG/9LS021Yanu2fHS3MsxgeYsw/vSd3a4KdxpCluJMkyPZ7WRGlT2S+tKHZrs5xnkRQ7/d7s3jTjagDB9acI4LXKXdc8cWsY+crA4HyPuJP6tIKoWyq4LYJ/RD/Szo4+EH0SuDA9GmMj0YsZFhukswnsfjZkJT9Utwv5RtcDBONrbEADEbVH+cMQ6THhEylgR3NQHsWfU6kQ1H7Crr+72PRHeoWlVwNS9DoODO6Ve0jZCY4CSeiGIQ869fliCa6ZWSSdCVGshpV9xnuwDlE8R/yqZTcR17p8Rbsm/VG5oKQbNCDKAk2tZeqTpzFyxgKnlv9s1QhN9/Hh4OnSqCT5Y62NUdDCasE+35epGEnugMrdp98Xzs54Tp5iFzjhWlp84uUULbg/pvvWIdQ/AqNBk/s+Qd+u0cXBYVse4XCIY1IixFa+4rWvR1jpEYBza9wSeD4f5G771r0SG31EPnLVx9IxjqhM0ZJa7PVVlf5ozglhn+Gh54tPwQ0ZacKPK6Qg2ueTYvSpExMkxOstNjdfiUVN1tvZAhXDxI3jifQLLjh1296mi5FJcMrbk3dz9uGx2cf5axVzaTvSjK+IiCj3BhvYofHGpV/XnURIVQFVyOta9F61ef9ZMuEls4xE254lGw/b+s9i6N7/SkwLrbJVmHIZ9dL9JNtUT0gksIFaKH0LaQ3R220brrqH9DszUqWF/oUSEGi+7eRnuGK/5/WpzS5zjH9HFLtv776miM1tPuHpVZl20YM/LLqK45o/1UBdPLpeg4L1QMvMM72zqevKIbCVsOi7N47c1ieHvr7wX4dKMQfR/dMlAyFbYFknHEOwdHOOpwC2pbSMil51DUV/BP5118CEJhE8fmu0EBYNNUixPDocc2fE9PoNjsIt7Q 7r+I9fsU 3sv5IEJZVVwlujPuDVM4q/NO1S+AukhOGhFWISuqFRsRBAOFUUogTq3xWwvkqxcb5Qc/aIDaJjmOUdRXx4zMzMDQStOiSy9PSOEdQUdSXfqNZ7su6Ejgp3M2++9CUA6VAkH69By3b+dxq8tj4dnwGNlcFvtC93LOI2OAj8+0geHyQQyEuD/ybUSpxBCCSbohoXHl4yi492+Ty5RDC4ibaffD0GR6cx5c1RvzkoJbNZwbPGOt76euzeFvOXNyCahJN819/QOQAIWwCFkPBEUzrrMOZ9Zn0IPVGL48C2FZ8cE4vrL/Ob0bmf5fnvK448Gm3Y30N X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 7/18/23 13:26, Alistair Popple wrote: > The main change is to move secondary TLB invalidation mmu notifier > callbacks into the architecture specific TLB flushing functions. This > makes secondary TLB invalidation mostly match CPU invalidation while > still allowing efficient range based invalidations based on the > existing TLB batching code. > > ========== > Background > ========== > > The arm64 architecture specifies TLB permission bits may be cached and > therefore the TLB must be invalidated during permission upgrades. For > the CPU this currently occurs in the architecture specific > ptep_set_access_flags() routine. > > Secondary TLBs such as implemented by the SMMU IOMMU match the CPU > architecture specification and may also cache permission bits and > require the same TLB invalidations. This may be achieved in one of two > ways. > > Some SMMU implementations implement broadcast TLB maintenance > (BTM). This snoops CPU TLB invalidates and will invalidate any > secondary TLB at the same time as the CPU. However implementations are > not required to implement BTM. So, the implementations with BTM do not even need a MMU notifier callback for secondary TLB invalidation purpose ? Perhaps mmu_notifier_register() could also be skipped for such cases i.e with ARM_SMMU_FEAT_BTM enabled ? BTW, dont see ARM_SMMU_FEAT_BTM being added as a feature any where during the probe i.e arm_smmu_device_hw_probe(). > > Implementations without BTM rely on mmu notifier callbacks to send > explicit TLB invalidation commands to invalidate SMMU TLB. Therefore > either generic kernel code or architecture specific code needs to call > the mmu notifier on permission upgrade. > > Currently that doesn't happen so devices will fault indefinitely when > writing to a PTE that was previously read-only as nothing invalidates > the SMMU TLB. Why does not the current SMMU MMU notifier intercept all invalidation from generic MM code and do the required secondary TLB invalidation ? Is there a timing issue involved here ? Secondary TLB invalidation does happen but after the damage has been done ? Could you please point us to a real world bug report taking such indefinite faults as mentioned above ? > > ======== > Solution > ======== > > To fix this the series first renames the .invalidate_range() callback > to .arch_invalidate_secondary_tlbs() as suggested by Jason and Sean to > make it clear this callback is only used for secondary TLBs. That was > made possible thanks to Sean's series [1] to remove KVM's incorrect > usage. > > Based on feedback from Jason [2] the proposed solution to the bug is > to move the calls to mmu_notifier_arch_invalidate_secondary_tlbs() > closer to the architecture specific TLB invalidation code. This > ensures the secondary TLB won't miss invalidations, including the > existing invalidation in the ARM64 code to deal with permission > upgrade. ptep_set_access_flags() is the only problematic place where this issue is being reported ? If yes, why dont fix that instead of moving these into platform specific callbacks ? OR there are other problematic areas I might be missing. > > Currently only ARM64, PowerPC and x86 have IOMMU with secondary TLBs > requiring SW invalidation so the notifier is only called for those > architectures. It is also not called for invalidation of kernel > mappings as no secondary IOMMU implementations can access those and > hence it is not required. > > [1] - https://lore.kernel.org/all/20230602011518.787006-1-seanjc@google.com/ > [2] - https://lore.kernel.org/linux-mm/ZJMR5bw8l+BbzdJ7@ziepe.ca/ > > Alistair Popple (4): > mm_notifiers: Rename invalidate_range notifier > arm64/smmu: Use TLBI ASID when invalidating entire range > mmu_notifiers: Call arch_invalidate_secondary_tlbs() when invalidating TLBs > mmu_notifiers: Don't invalidate secondary TLBs as part of mmu_notifier_invalidate_range_end() > > arch/arm64/include/asm/tlbflush.h | 5 +- > arch/powerpc/include/asm/book3s/64/tlbflush.h | 1 +- > arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 1 +- > arch/powerpc/mm/book3s64/radix_tlb.c | 6 +- > arch/x86/mm/tlb.c | 3 +- > drivers/iommu/amd/iommu_v2.c | 10 +- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 29 +++-- > drivers/iommu/intel/svm.c | 8 +- > drivers/misc/ocxl/link.c | 8 +- > include/asm-generic/tlb.h | 1 +- > include/linux/mmu_notifier.h | 104 ++++------------- > kernel/events/uprobes.c | 2 +- > mm/huge_memory.c | 29 +---- > mm/hugetlb.c | 8 +- > mm/memory.c | 8 +- > mm/migrate_device.c | 9 +- > mm/mmu_notifier.c | 47 +++----- > mm/rmap.c | 40 +------- > 18 files changed, 109 insertions(+), 210 deletions(-) > > base-commit: fdf0eaf11452d72945af31804e2a1048ee1b574c