public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Yeoreum Yun <yeoreum.yun@arm.com>, Marc Zyngier <maz@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev,
	kvm@vger.kernel.org, linux-kselftest@vger.kernel.org,
	catalin.marinas@arm.com, will@kernel.org, oupton@kernel.org,
	miko.lenczewski@arm.com, kevin.brodsky@arm.com,
	broonie@kernel.org, ardb@kernel.org, lpieralisi@kernel.org,
	joey.gouly@arm.com, yuzenghui@huawei.com
Subject: Re: [PATCH v14 7/8] KVM: arm64: use CASLT instruction for swapping guest descriptor
Date: Thu, 26 Feb 2026 14:52:47 +0000	[thread overview]
Message-ID: <ec3fc327-042a-4672-ab39-88cd1ce41065@arm.com> (raw)
In-Reply-To: <aaBTM3C2MbIvtUn8@e129823.arm.com>

On 26/02/2026 14:05, Yeoreum Yun wrote:
> Hi Marc,
> 
>> On Wed, 25 Feb 2026 18:27:07 +0000,
>> Yeoreum Yun <yeoreum.yun@arm.com> wrote:
>>>
>>> Use the CASLT instruction to swap the guest descriptor when FEAT_LSUI
>>> is enabled, avoiding the need to clear the PAN bit.
>>>
>>> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
>>> ---
>>>   arch/arm64/include/asm/cpucaps.h |  2 ++
>>>   arch/arm64/include/asm/futex.h   | 17 +----------------
>>>   arch/arm64/include/asm/lsui.h    | 27 +++++++++++++++++++++++++++
>>>   arch/arm64/kvm/at.c              | 30 +++++++++++++++++++++++++++++-
>>>   4 files changed, 59 insertions(+), 17 deletions(-)
>>>   create mode 100644 arch/arm64/include/asm/lsui.h
>>>
>>> diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
>>> index 177c691914f8..6e3da333442e 100644
>>> --- a/arch/arm64/include/asm/cpucaps.h
>>> +++ b/arch/arm64/include/asm/cpucaps.h
>>> @@ -71,6 +71,8 @@ cpucap_is_possible(const unsigned int cap)
>>>   		return true;
>>>   	case ARM64_HAS_PMUV3:
>>>   		return IS_ENABLED(CONFIG_HW_PERF_EVENTS);
>>> +	case ARM64_HAS_LSUI:
>>> +		return IS_ENABLED(CONFIG_ARM64_LSUI);
>>>   	}
>>>
>>>   	return true;
>>
>> It would make more sense to move this hunk to the first patch, where
>> you deal with features and capabilities, instead of having this in a
>> random KVM-specific patch.
> 
> Okay. But as Suzuki mention, I think it seems to be redundant.
> I'll remove it.
> 

No, this is required and Marc is right. This hunk should be part of the
original patch that adds the cap. What I am saying is that you don't
need to explicitly call the cpucap_is_poissible() down, but it is
implicitly called by cpus_have_final_cap().

Kind regards
Suzuki


>>
>>> diff --git a/arch/arm64/include/asm/futex.h b/arch/arm64/include/asm/futex.h
>>> index b579e9d0964d..6779c4ad927f 100644
>>> --- a/arch/arm64/include/asm/futex.h
>>> +++ b/arch/arm64/include/asm/futex.h
>>> @@ -7,11 +7,9 @@
>>>
>>>   #include <linux/futex.h>
>>>   #include <linux/uaccess.h>
>>> -#include <linux/stringify.h>
>>>
>>> -#include <asm/alternative.h>
>>> -#include <asm/alternative-macros.h>
>>>   #include <asm/errno.h>
>>> +#include <asm/lsui.h>
>>>
>>>   #define FUTEX_MAX_LOOPS	128 /* What's the largest number you can think of? */
>>>
>>> @@ -91,8 +89,6 @@ __llsc_futex_cmpxchg(u32 __user *uaddr, u32 oldval, u32 newval, u32 *oval)
>>>
>>>   #ifdef CONFIG_ARM64_LSUI
>>>
>>> -#define __LSUI_PREAMBLE	".arch_extension lsui\n"
>>> -
>>>   #define LSUI_FUTEX_ATOMIC_OP(op, asm_op)				\
>>>   static __always_inline int						\
>>>   __lsui_futex_atomic_##op(int oparg, u32 __user *uaddr, int *oval)	\
>>> @@ -235,17 +231,6 @@ __lsui_futex_cmpxchg(u32 __user *uaddr, u32 oldval, u32 newval, u32 *oval)
>>>   {
>>>   	return __lsui_cmpxchg32(uaddr, oldval, newval, oval);
>>>   }
>>> -
>>> -#define __lsui_llsc_body(op, ...)					\
>>> -({									\
>>> -	alternative_has_cap_unlikely(ARM64_HAS_LSUI) ?			\
>>> -		__lsui_##op(__VA_ARGS__) : __llsc_##op(__VA_ARGS__);	\
>>> -})
>>> -
>>> -#else	/* CONFIG_ARM64_LSUI */
>>> -
>>> -#define __lsui_llsc_body(op, ...)	__llsc_##op(__VA_ARGS__)
>>> -
>>>   #endif	/* CONFIG_ARM64_LSUI */
>>>
>>>
>>> diff --git a/arch/arm64/include/asm/lsui.h b/arch/arm64/include/asm/lsui.h
>>> new file mode 100644
>>> index 000000000000..8f0d81953eb6
>>> --- /dev/null
>>> +++ b/arch/arm64/include/asm/lsui.h
>>> @@ -0,0 +1,27 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +#ifndef __ASM_LSUI_H
>>> +#define __ASM_LSUI_H
>>> +
>>> +#include <linux/compiler_types.h>
>>> +#include <linux/stringify.h>
>>> +#include <asm/alternative.h>
>>> +#include <asm/alternative-macros.h>
>>> +#include <asm/cpucaps.h>
>>> +
>>> +#define __LSUI_PREAMBLE	".arch_extension lsui\n"
>>> +
>>> +#ifdef CONFIG_ARM64_LSUI
>>> +
>>> +#define __lsui_llsc_body(op, ...)					\
>>> +({									\
>>> +	alternative_has_cap_unlikely(ARM64_HAS_LSUI) ?			\
>>> +		__lsui_##op(__VA_ARGS__) : __llsc_##op(__VA_ARGS__);	\
>>> +})
>>> +
>>> +#else	/* CONFIG_ARM64_LSUI */
>>> +
>>> +#define __lsui_llsc_body(op, ...)	__llsc_##op(__VA_ARGS__)
>>> +
>>> +#endif	/* CONFIG_ARM64_LSUI */
>>> +
>>> +#endif	/* __ASM_LSUI_H */
>>
>> Similarly, fold this into the patch that introduces FEAT_LSUI support
>> for futexes (#5) so that the code is in its final position from the
>> beginning. This will avoid churn that makes the patches pointlessly
>> hard to follow, since this change is unrelated to KVM.
> 
> Okay. I'll fold it into #5.
> 
>>
>>> diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c
>>> index 885bd5bb2f41..fd3c5749e853 100644
>>> --- a/arch/arm64/kvm/at.c
>>> +++ b/arch/arm64/kvm/at.c
>>> @@ -9,6 +9,7 @@
>>>   #include <asm/esr.h>
>>>   #include <asm/kvm_hyp.h>
>>>   #include <asm/kvm_mmu.h>
>>> +#include <asm/lsui.h>
>>>
>>>   static void fail_s1_walk(struct s1_walk_result *wr, u8 fst, bool s1ptw)
>>>   {
>>> @@ -1704,6 +1705,31 @@ int __kvm_find_s1_desc_level(struct kvm_vcpu *vcpu, u64 va, u64 ipa, int *level)
>>>   	}
>>>   }
>>>
>>> +static int __lsui_swap_desc(u64 __user *ptep, u64 old, u64 new)
>>> +{
>>> +	u64 tmp = old;
>>> +	int ret = 0;
>>> +
>>> +	uaccess_ttbr0_enable();
>>
>> Why do we need this? If FEAT_LSUI is present, than FEAT_PAN is also
>> present. And since PAN support not a compilation option anymore, we
>> should be able to rely on PAN being enabled.
>>
>> Or am I missing something? If so, please document why we require it.
> 
> That was my origin thought but there was relevant discussion about this:
>    - https://lore.kernel.org/all/aW5dzb0ldp8u8Rdm@willie-the-truck/
>    - https://lore.kernel.org/all/aYtZfpWjRJ1r23nw@arm.com/
> 
> In summary, I couldn't make that assumption --
> PAN always presents when LSUI presents for :
> 
>     - CPU bugs happen all the time
>     - Virtualisation and idreg overrides mean illegal feature combinations
>      can show up
> 
> So, uaccess_ttbr0_enable() is for when SW_PAN is enabled.
> 
> I'll make a comment for this.
> 
> [...]
> 
> Thanks!
> 
> --
> Sincerely,
> Yeoreum Yun



  reply	other threads:[~2026-02-26 14:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-25 18:27 [PATCH v14 0/8] support FEAT_LSUI Yeoreum Yun
2026-02-25 18:27 ` [PATCH v14 1/8] arm64: cpufeature: add FEAT_LSUI Yeoreum Yun
2026-02-25 18:27 ` [PATCH v14 2/8] KVM: arm64: expose FEAT_LSUI to guest Yeoreum Yun
2026-02-25 18:27 ` [PATCH v14 3/8] KVM: arm64: kselftest: set_id_regs: add test for FEAT_LSUI Yeoreum Yun
2026-02-25 18:27 ` [PATCH v14 4/8] arm64: futex: refactor futex atomic operation Yeoreum Yun
2026-02-25 18:27 ` [PATCH v14 5/8] arm64: futex: support futex with FEAT_LSUI Yeoreum Yun
2026-02-25 18:27 ` [PATCH v14 6/8] arm64: armv8_deprecated: disable swp emulation when FEAT_LSUI present Yeoreum Yun
2026-02-25 18:27 ` [PATCH v14 7/8] KVM: arm64: use CASLT instruction for swapping guest descriptor Yeoreum Yun
2026-02-26 11:16   ` Marc Zyngier
2026-02-26 14:05     ` Yeoreum Yun
2026-02-26 14:52       ` Suzuki K Poulose [this message]
2026-02-27  8:31         ` Yeoreum Yun
2026-02-26 11:28   ` Suzuki K Poulose
2026-02-26 13:53     ` Yeoreum Yun
2026-02-26 11:38   ` Oliver Upton
2026-02-26 13:52     ` Yeoreum Yun
2026-02-25 18:27 ` [PATCH v14 8/8] arm64: Kconfig: add support for LSUI Yeoreum Yun

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=ec3fc327-042a-4672-ab39-88cd1ce41065@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=ardb@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=kevin.brodsky@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=maz@kernel.org \
    --cc=miko.lenczewski@arm.com \
    --cc=oupton@kernel.org \
    --cc=will@kernel.org \
    --cc=yeoreum.yun@arm.com \
    --cc=yuzenghui@huawei.com \
    /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