[PATCH v5 0/5] support FEAT_LSUI and apply it on futex atomic ops

Yeoreum Yun posted 5 patches 2 months, 2 weeks ago
There is a newer version of this series
arch/arm64/Kconfig             |   5 +
arch/arm64/include/asm/futex.h | 323 +++++++++++++++++++++++++++------
arch/arm64/kernel/cpufeature.c |   8 +
arch/arm64/kvm/sys_regs.c      |   5 +-
arch/arm64/tools/cpucaps       |   1 +
5 files changed, 281 insertions(+), 61 deletions(-)
[PATCH v5 0/5] support FEAT_LSUI and apply it on futex atomic ops
Posted by Yeoreum Yun 2 months, 2 weeks ago
Since Armv9.6, FEAT_LSUI supplies the load/store instructions for
previleged level to access to access user memory without clearing
PSTATE.PAN bit.

This patchset support FEAT_LSUI and applies in futex atomic operation
where can replace from ldxr/stlxr pair implmentation with clearing
PSTATE.PAN bit to correspondant load/store unprevileged atomic operation
without clearing PSTATE.PAN bit.

Patch Sequences
================

Patch #1 adds cpufeature for FEAT_LSUI

Patch #2 expose FEAT_LSUI to guest

Patch #3 adds Kconfig for FEAT_LSUI

Patch #4 refactor former futex atomic-op implmentation with ll/sc &
         clearing PSTATE.PAN

Patch #5 support futext atomic-op with FEAT_LSUI

Patch History
==============
from v4 to v5:
  - remove futex_ll_sc.h futext_lsui and lsui.h and move them to futex.h
  - reorganize the patches.
  - https://lore.kernel.org/all/20250721083618.2743569-1-yeoreum.yun@arm.com/

from v3 to v4:
  - rebase to v6.16-rc7
  - modify some patch's title.
  - https://lore.kernel.org/all/20250617183635.1266015-1-yeoreum.yun@arm.com/

from v2 to v3:
  - expose FEAT_LUSI to guest
  - add help section for LUSI Kconfig
  - https://lore.kernel.org/all/20250611151154.46362-1-yeoreum.yun@arm.com/

from v1 to v2:
  - remove empty v9.6 menu entry
  - locate HAS_LUSI in cpucaps in order
  - https://lore.kernel.org/all/20250611104916.10636-1-yeoreum.yun@arm.com/

Yeoreum Yun (5):
  arm64: cpufeature: add FEAT_LSUI
  KVM: arm64: expose FEAT_LSUI to guest
  arm64: Kconfig: add LSUI Kconfig
  arm64: futex: refactor futex atomic operation
  arm64: futex: support futex with FEAT_LSUI

 arch/arm64/Kconfig             |   5 +
 arch/arm64/include/asm/futex.h | 323 +++++++++++++++++++++++++++------
 arch/arm64/kernel/cpufeature.c |   8 +
 arch/arm64/kvm/sys_regs.c      |   5 +-
 arch/arm64/tools/cpucaps       |   1 +
 5 files changed, 281 insertions(+), 61 deletions(-)

--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
Re: [PATCH v5 0/5] support FEAT_LSUI and apply it on futex atomic ops
Posted by Marc Zyngier 2 months, 2 weeks ago
Hi Yeoreum,

On Tue, 22 Jul 2025 13:19:51 +0100,
Yeoreum Yun <yeoreum.yun@arm.com> wrote:
> 
> Since Armv9.6, FEAT_LSUI supplies the load/store instructions for
> previleged level to access to access user memory without clearing
> PSTATE.PAN bit.
> 
> This patchset support FEAT_LSUI and applies in futex atomic operation
> where can replace from ldxr/stlxr pair implmentation with clearing
> PSTATE.PAN bit to correspondant load/store unprevileged atomic operation
> without clearing PSTATE.PAN bit.

[...]

Please give people a chance to review your series without having to
jump to the new one within 48 hours. If anything, it actively prevents
people from reviewing it (why would I review it, since the author is
going to post a new version in a couple of days...).

Also, given that we're >this< close to the next merge window, I don't
think this series is likely to be a candidate for 6.17. Give yourself
the space to polish the series and look at it with a critical eye,
there is plenty of time for 6.18.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.
Re: [PATCH v5 0/5] support FEAT_LSUI and apply it on futex atomic ops
Posted by Yeoreum Yun 2 months, 2 weeks ago
Hi Marc,

[...]
>
> Please give people a chance to review your series without having to
> jump to the new one within 48 hours. If anything, it actively prevents
> people from reviewing it (why would I review it, since the author is
> going to post a new version in a couple of days...).
>
> Also, given that we're >this< close to the next merge window, I don't
> think this series is likely to be a candidate for 6.17. Give yourself
> the space to polish the series and look at it with a critical eye,
> there is plenty of time for 6.18.
>
> Thanks,
>
> 	M.

Thanks to let me know and sorry for being impatient ...

--
Sincerely,
Yeoreum Yun