From: Alistair Popple <apopple@nvidia.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
robin.murphy@arm.com, will@kernel.org, nicolinc@nvidia.com,
linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org,
jgg@nvidia.com, John Hubbard <jhubbard@nvidia.com>
Subject: Re: [PATCH] mmu_notifiers: Notify on pte permission upgrades
Date: Tue, 23 May 2023 10:43:17 +1000 [thread overview]
Message-ID: <87wn0z98n7.fsf@nvidia.com> (raw)
In-Reply-To: <ZGwDoONUFAHi7XKz@google.com>
Sean Christopherson <seanjc@google.com> writes:
> On Tue, May 23, 2023, Alistair Popple wrote:
>>
>> Sean Christopherson <seanjc@google.com> writes:
[...]
>> > * If invalidate_range() is used to manage a non-CPU TLB with
>> > * shared page-tables, it not necessary to implement the
>> > * invalidate_range_start()/end() notifiers, as
>> > * invalidate_range() already catches the points in time when an
>> > * external TLB range needs to be flushed. For more in depth
>> > * discussion on this see Documentation/mm/mmu_notifier.rst
>> >
>> > Even worse, this change may silently regress performance for secondary MMUs that
>> > haven't yet taken advantage of the event type, e.g. KVM will zap all of KVM's PTEs
>> > in response to the upgrade, instead of waiting until the guest actually tries to
>> > utilize the new protections.
>>
>> Yeah, I like the idea of introducing a
>> ptep_set_access_flags_notify(). That way this won't regress performance
>> on platforms that don't need it. Note this isn't a new feature but
>> rather a bugfix. It's unclear to me why KVM on ARM hasn't already run
>> into this issue, but I'm no KVM expert. Thanks for the feedback.
>
> KVM manages its own page tables and so does its own TLB invalidations as needed,
> e.g. KVM can and does change KVM's stage-2 PTEs from read-only to read/write
> irrespective of mmu_notifiers. I assume the SMMU issue arises only because the
> SMMU is reusing the host kernel's (stage-1?) page tables.
Argh, thanks. That makes sense. The SMMU issue arises because it is not
snooping CPU TLB invalidations and therefore relies entirely on notifier
callbacks to invalidate it's TLB. If it was snooping invalidations it
would observe the TLB invalidation ARM64 does in
ptep_set_access_flags()[1]. Now that I've figured out we can call
invalidate_range() under the PTL I think I can just add the notifier
call there.
[1] - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/mm/fault.c?id=ae8373a5add4ea39f032563cf12a02946d1e3546#n229
next prev parent reply other threads:[~2023-05-23 0:47 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-22 6:37 Alistair Popple
2023-05-22 7:15 ` Qi Zheng
2023-05-22 7:45 ` Alistair Popple
2023-05-22 8:28 ` Qi Zheng
2023-05-22 15:09 ` Catalin Marinas
2023-05-22 23:52 ` Alistair Popple
2023-05-22 18:34 ` Sean Christopherson
2023-05-22 23:50 ` Alistair Popple
2023-05-23 0:06 ` Sean Christopherson
2023-05-23 0:43 ` Alistair Popple [this message]
2023-05-23 1:13 ` John Hubbard
2023-05-23 4:35 ` Alistair Popple
2023-05-23 0:55 ` John Hubbard
2023-05-23 1:12 ` Alistair Popple
2023-05-23 6:45 ` Christoph Hellwig
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=87wn0z98n7.fsf@nvidia.com \
--to=apopple@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=jgg@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=kvm@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nicolinc@nvidia.com \
--cc=robin.murphy@arm.com \
--cc=seanjc@google.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