[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65350c17-3fcf-a057-a280-f6a5d36dcb21@efficios.com>
Date: Fri, 4 Aug 2023 10:20:16 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Andrea Parri <parri.andrea@...il.com>
Cc: paulmck@...nel.org, paul.walmsley@...ive.com, palmer@...belt.com,
aou@...s.berkeley.edu, linux-riscv@...ts.infradead.org,
linux-kernel@...r.kernel.org, mmaas@...gle.com, hboehm@...gle.com,
striker@...ibm.com
Subject: Re: [RFC PATCH] membarrier: riscv: Provide core serializing command
On 8/3/23 20:16, Andrea Parri wrote:
>> Can you double-check that riscv switch_mm() implies a fence.i or equivalent
>> on the CPU doing the switch_mm ?
>
> AFAICT, (riscv) switch_mm() does not guarantee that.
>
>
>> AFAIR membarrier use of sync_core_before_usermode relies on switch_mm
>> issuing a core serializing instruction.
>
> I see. Thanks for the clarification.
>
> BTW, the comment in __schedule() suggests that membarrier also relies on
> switch_mm() issuing a full memory barrier: I don't think this holds.
>
> Removing the "deferred icache flush" logic in switch_mm() - in favour of
> a "plain" MB; FENCE.I - would meet both of these requirements.
What is the relationship between FENCE.I and instruction cache flush on
RISC-V ?
On other architectures, there is need for careful flushing of the
instruction cache for the address range that was modified, _and_ to
issue a core serializing instruction on all cores (this last part being
performed by membarrier SYNC_CORE) between the point where the old
instructions were executed and before the new instructions are executed.
Thanks,
Mathieu
>
> Other ideas?
>
> Andrea
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
Powered by blists - more mailing lists