From: Catalin Marinas <catalin.marinas@arm.com>
To: Mohamed Husain Noor Mohamed <nkhusain@vt.edu>
Cc: linux-arm-kernel@lists.infradead.org,
Anshuman Khandual <anshuman.khandual@arm.com>,
Will Deacon <will@kernel.org>
Subject: Re: ARM64: Adding write-protect bit for Userfaultfd
Date: Tue, 2 May 2023 14:36:09 +0100 [thread overview]
Message-ID: <ZFERyRlp3gStbjIQ@arm.com> (raw)
In-Reply-To: <CAEf7hy2OD8XcFiSjDcqjzjpBFRYTeQL2hxoMuS8KFxXRJjr7tA@mail.gmail.com>
On Fri, Apr 28, 2023 at 01:35:44PM -0400, Mohamed Husain Noor Mohamed wrote:
> I am Mohamed Husain. I am a graduate student, working on a research
> project using a userfaultfd for distributed shared memory.
> We are trying to use Write-Protect mode in ARM64 but based on the
> kernel commits we see the support only exists for the x86 kernel.
> https://lwn.net/Articles/777258/
>
> I am trying to add the write-protect support, so I am looking for the
> unused bits in the PTE. Do you guys have any suggestions on the bits I
> could use, or does it require hardware support?
Unfortunately, we are pretty short on bits. The architecture only gives
us bits 55 to 58 and they are all used. We could move PTE_PROT_NONE to
another position (e.g. 60) since this is only used when !PTE_VALID and
therefore doesn't affect the actual page attributes and free up a bit.
Alternatively, we could hijack bits 59-62 but there may be out of tree
patches making use of the PBHA imp def feature (AFAICT disabled on the
mainline kernel). Well, I guess one could make the userfaultfd wp
feature conditional.
Cc'ing Anshuman as well, I think he looked at soft-dirty ptes for arm64
before for CRIU live migration and we concluded that userfaultfd was
better but I didn't realise that the write-protect mechanism needs its
own PTE bit as well.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-05-02 13:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-28 17:35 ARM64: Adding write-protect bit for Userfaultfd Mohamed Husain Noor Mohamed
2023-05-02 13:36 ` Catalin Marinas [this message]
2023-05-17 15:43 ` Mohamed Husain Noor Mohamed
2023-05-18 12:28 ` Joey Gouly
2023-05-22 16:38 ` Catalin Marinas
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=ZFERyRlp3gStbjIQ@arm.com \
--to=catalin.marinas@arm.com \
--cc=anshuman.khandual@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=nkhusain@vt.edu \
--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).