From: Deepak Gupta <debug@rivosinc.com>
To: Chunyan Zhang <zhang.lyra@gmail.com>
Cc: "Björn Töpel" <bjorn@kernel.org>,
"Chunyan Zhang" <zhangchunyan@iscas.ac.cn>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Alexandre Ghiti" <alex@ghiti.fr>,
"Andrew Morton" <akpm@linux-foundation.org>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
"Alistair Popple" <apopple@nvidia.com>,
linux-mm@kvack.org
Subject: Re: [PATCH V5 1/3] riscv: mm: Prepare for reusing PTE RSW bit(9)
Date: Thu, 20 Feb 2025 10:23:00 -0800 [thread overview]
Message-ID: <Z7dzBH7SNN7SP3+5@debug.ba.rivosinc.com> (raw)
In-Reply-To: <CAAfSe-sf+4QY9eif_XaRGXEUn1JyPn_Jj+k2MOq9mfDR2Bd6yg@mail.gmail.com>
Sorry for the late response.
On Tue, Feb 11, 2025 at 04:05:02PM +0800, Chunyan Zhang wrote:
>On Tue, 11 Feb 2025 at 12:01, Deepak Gupta <debug@rivosinc.com> wrote:
>>
>> On Tue, Feb 11, 2025 at 09:20:22AM +0800, Chunyan Zhang wrote:
>> >On Thu, 30 Jan 2025 at 16:42, Björn Töpel <bjorn@kernel.org> wrote:
>> >>
>> >> Chunyan Zhang <zhangchunyan@iscas.ac.cn> writes:
>> >>
>> >> > The PTE bit(9) on RISC-V is reserved for software, it is used by devmap
>> >> > now which has to be disabled if we want to use bit(9) for other features,
>> >> > since there's no more free PTE bit on RISC-V now.
>> >> >
>> >> > So to make ARCH_HAS_PTE_DEVMAP selectable, this patch uses it as
>> >> > the build condition of devmap definitions.
>> >>
>> >> Heads-up: It seems like Alistair's series [1] that removes the devmap
>> >> PTE bit will most likely land in 6.15.
>> >
>> >Yes, I've been keeping an eye on Alistair's series, intended to update
>> >this patchset after Alistair's patch that removes the devmap PTE bit
>> >got merged.
>>
>> Please keep in mind that even after claiming back devmap PTE SW bit, a compile
>> time decision to select between uffd-wp and soft-dirty is not desirable.
>
>Yes, I agree. I've read your aother email. I also hope we can have
>more RSW bits to use. So should we add uffd-wp and soft-dirty support
>on RISC-V until we have two RSW bits for these two functions? Is an
>undesirable solution better than no solution for now?
Problem is that this undesirable solution doesn't solve anything for *most* users.
Kernel can't deviate from providing functionality (which is actually arch-agnostic) to
user mode depending on the architecture.
>I can optimize the code when we have more free RSW bits, that's not hard.
We got 3 use cases,
- pfnmap/pte_special
- uffd-wp
- softdirty
4th one for devmap, I hope we don't need to do it. Should get it back.
https://lore.kernel.org/lkml/cover.95ff0627bc727f2bae44bea4c00ad7a83fbbcfac.1739941374.git-series.apopple@nvidia.com/#r
It looks like any work there would be wasted time.
There is a (fast track) proposal out there to get 2 more RSW bits.
https://lists.riscv.org/g/tech-privileged/message/2268
I hope it gets ratified soon. We will have proper solution to this problem then.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Deepak Gupta <debug@rivosinc.com>
To: Chunyan Zhang <zhang.lyra@gmail.com>
Cc: "Björn Töpel" <bjorn@kernel.org>,
"Chunyan Zhang" <zhangchunyan@iscas.ac.cn>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Alexandre Ghiti" <alex@ghiti.fr>,
"Andrew Morton" <akpm@linux-foundation.org>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
"Alistair Popple" <apopple@nvidia.com>,
linux-mm@kvack.org
Subject: Re: [PATCH V5 1/3] riscv: mm: Prepare for reusing PTE RSW bit(9)
Date: Thu, 20 Feb 2025 10:23:00 -0800 [thread overview]
Message-ID: <Z7dzBH7SNN7SP3+5@debug.ba.rivosinc.com> (raw)
In-Reply-To: <CAAfSe-sf+4QY9eif_XaRGXEUn1JyPn_Jj+k2MOq9mfDR2Bd6yg@mail.gmail.com>
Sorry for the late response.
On Tue, Feb 11, 2025 at 04:05:02PM +0800, Chunyan Zhang wrote:
>On Tue, 11 Feb 2025 at 12:01, Deepak Gupta <debug@rivosinc.com> wrote:
>>
>> On Tue, Feb 11, 2025 at 09:20:22AM +0800, Chunyan Zhang wrote:
>> >On Thu, 30 Jan 2025 at 16:42, Björn Töpel <bjorn@kernel.org> wrote:
>> >>
>> >> Chunyan Zhang <zhangchunyan@iscas.ac.cn> writes:
>> >>
>> >> > The PTE bit(9) on RISC-V is reserved for software, it is used by devmap
>> >> > now which has to be disabled if we want to use bit(9) for other features,
>> >> > since there's no more free PTE bit on RISC-V now.
>> >> >
>> >> > So to make ARCH_HAS_PTE_DEVMAP selectable, this patch uses it as
>> >> > the build condition of devmap definitions.
>> >>
>> >> Heads-up: It seems like Alistair's series [1] that removes the devmap
>> >> PTE bit will most likely land in 6.15.
>> >
>> >Yes, I've been keeping an eye on Alistair's series, intended to update
>> >this patchset after Alistair's patch that removes the devmap PTE bit
>> >got merged.
>>
>> Please keep in mind that even after claiming back devmap PTE SW bit, a compile
>> time decision to select between uffd-wp and soft-dirty is not desirable.
>
>Yes, I agree. I've read your aother email. I also hope we can have
>more RSW bits to use. So should we add uffd-wp and soft-dirty support
>on RISC-V until we have two RSW bits for these two functions? Is an
>undesirable solution better than no solution for now?
Problem is that this undesirable solution doesn't solve anything for *most* users.
Kernel can't deviate from providing functionality (which is actually arch-agnostic) to
user mode depending on the architecture.
>I can optimize the code when we have more free RSW bits, that's not hard.
We got 3 use cases,
- pfnmap/pte_special
- uffd-wp
- softdirty
4th one for devmap, I hope we don't need to do it. Should get it back.
https://lore.kernel.org/lkml/cover.95ff0627bc727f2bae44bea4c00ad7a83fbbcfac.1739941374.git-series.apopple@nvidia.com/#r
It looks like any work there would be wasted time.
There is a (fast track) proposal out there to get 2 more RSW bits.
https://lists.riscv.org/g/tech-privileged/message/2268
I hope it gets ratified soon. We will have proper solution to this problem then.
next prev parent reply other threads:[~2025-02-20 18:25 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-13 9:58 [PATCH V5 0/3] riscv: mm: Add soft-dirty and uffd-wp support Chunyan Zhang
2024-11-13 9:58 ` Chunyan Zhang
2024-11-13 9:58 ` [PATCH V5 1/3] riscv: mm: Prepare for reusing PTE RSW bit(9) Chunyan Zhang
2024-11-13 9:58 ` Chunyan Zhang
2025-01-30 8:42 ` Björn Töpel
2025-01-30 8:42 ` Björn Töpel
2025-02-05 0:19 ` Alistair Popple
2025-02-05 0:19 ` Alistair Popple
2025-02-11 1:20 ` Chunyan Zhang
2025-02-11 1:20 ` Chunyan Zhang
2025-02-11 4:01 ` Deepak Gupta
2025-02-11 4:01 ` Deepak Gupta
2025-02-11 8:05 ` Chunyan Zhang
2025-02-11 8:05 ` Chunyan Zhang
2025-02-20 18:23 ` Deepak Gupta [this message]
2025-02-20 18:23 ` Deepak Gupta
2024-11-13 9:58 ` [PATCH V5 2/3] riscv: mm: Add soft-dirty page tracking support Chunyan Zhang
2024-11-13 9:58 ` Chunyan Zhang
2024-11-13 9:58 ` [PATCH V5 3/3] riscv: mm: Add uffd write-protect support Chunyan Zhang
2024-11-13 9:58 ` Chunyan Zhang
2025-01-29 8:12 ` [PATCH V5 0/3] riscv: mm: Add soft-dirty and uffd-wp support Deepak Gupta
2025-01-29 8:12 ` Deepak Gupta
2025-03-30 13:51 ` Alexandre Ghiti
2025-03-30 13:51 ` Alexandre Ghiti
2025-03-31 2:00 ` Chunyan Zhang
2025-03-31 2:00 ` Chunyan Zhang
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=Z7dzBH7SNN7SP3+5@debug.ba.rivosinc.com \
--to=debug@rivosinc.com \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=apopple@nvidia.com \
--cc=bjorn@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=zhang.lyra@gmail.com \
--cc=zhangchunyan@iscas.ac.cn \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.