All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oupton@kernel.org>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.linux.dev, Joey Gouly <joey.gouly@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH 09/12] KVM: arm64: Add helper for swapping guest descriptor
Date: Mon, 17 Nov 2025 10:13:16 -0800	[thread overview]
Message-ID: <aRtlvNj9yMZoVb9g@kernel.org> (raw)
In-Reply-To: <86zf8ksq53.wl-maz@kernel.org>

On Mon, Nov 17, 2025 at 02:14:00PM +0000, Marc Zyngier wrote:
> On Wed, 12 Nov 2025 18:34:03 +0000,
> Oliver Upton <oupton@kernel.org> wrote:
> > +static int __llsc_swap_desc(u64 __user *ptep, u64 old, u64 new)
> > +{
> > +	unsigned int loops = 128;
> > +	u64 tmp;
> > +	int ret;
> > +
> > +	uaccess_enable_privileged();
> > +
> > +	asm volatile("prfm	pstl1strm, %[addr]\n"
> > +		     "1: ldxr	%[tmp], %[addr]\n"
> > +		     "sub	%[tmp], %[tmp], %[old]\n"
> > +		     "cbnz	%[tmp], 3f\n"
> > +		     "2: stlxr	%w[ret], %[new], %[addr]\n"
> > +		     "cbz	%w[ret], 4f\n"
> > +		     "sub	%w[loops], %w[loops], #1\n"
> > +		     "cbnz	%w[loops], 1b\n"
> > +		     "3: mov	%w[ret], %w[eagain]\n"
> > +		     "4:\n"
> > +		     : [ret] "=r" (ret), [addr] "+Q" (*ptep), [tmp] "=&r" (tmp),
> > +		       [loops] "+r" (loops)
> > +		     : [old] "r" (old), [new] "r" (new), [eagain] "Ir" (-EAGAIN)
> > +		     : "memory");
> 
> Why doesn't this need an exception table as well? I'd expect it to
> fault just as much as the LSE version (and ret cannot report -EFAULT,
> for example).

I just threw in ${something} to satisfy the LL/SC case, so yes, this
needs exception fixup as well.

> I'm also on the fence about the bounded loop. Yes, forward progress is
> a problem, but it should only affect large systems which can readily
> use the atomic instructions. I'd rather we get rid of it until proven
> that we really need something like it.

From a letter of the architecture POV I'm not sure we even need the
LL/SC implementation. As of now the only non-nested use case is the SEA
TTW walker which doesn't set the access flag (nor should it) and any
implementation that has FEAT_NV must also have FEAT_LSE.

I guess that just leaves the recursive NV case where a VMM explicitly
de-features FEAT_LSE. So I guess having a trivial, non-looping
implementation would be enough to cover this pointless issue.

Thanks,
Oliver

  reply	other threads:[~2025-11-17 18:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-12 18:33 [PATCH 00/12] KVM: arm64: nv: Implement FEAT_XNX and FEAT_HAF Oliver Upton
2025-11-12 18:33 ` [PATCH 01/12] arm64: Detect FEAT_XNX Oliver Upton
2025-11-12 18:33 ` [PATCH 02/12] KVM: arm64: Add support for FEAT_XNX stage-2 permissions Oliver Upton
2025-11-12 18:33 ` [PATCH 03/12] KVM: arm64: nv: Forward FEAT_XNX permissions to the shadow stage-2 Oliver Upton
2025-11-12 18:33 ` [PATCH 04/12] KVM: arm64: Teach ptdump about FEAT_XNX permissions Oliver Upton
2025-11-12 18:33 ` [PATCH 05/12] KVM: arm64: nv: Advertise support for FEAT_XNX Oliver Upton
2025-11-12 18:34 ` [PATCH 06/12] KVM: arm64: Call helper for reading descriptors directly Oliver Upton
2025-11-12 18:34 ` [PATCH 07/12] KVM: arm64: Handle endianness in read helper for emulated PTW Oliver Upton
2025-11-12 18:34 ` [PATCH 08/12] KVM: arm64: nv: Use pgtable definitions in stage-2 walk Oliver Upton
2025-11-12 18:34 ` [PATCH 09/12] KVM: arm64: Add helper for swapping guest descriptor Oliver Upton
2025-11-17 14:14   ` Marc Zyngier
2025-11-17 18:13     ` Oliver Upton [this message]
2025-11-12 18:34 ` [PATCH 10/12] KVM: arm64: Implement HW access flag management in stage-1 SW PTW Oliver Upton
2025-11-17 14:49   ` Marc Zyngier
2025-11-17 17:53     ` Oliver Upton
2025-11-12 18:34 ` [PATCH 11/12] KVM: arm64: nv: Implement HW access flag management in stage-2 " Oliver Upton
2025-11-17 14:51   ` Marc Zyngier
2025-11-12 18:34 ` [PATCH 12/12] KVM: arm64: nv: Expose hardware access flag management to NV guests Oliver Upton
2025-11-17 15:21 ` [PATCH 00/12] KVM: arm64: nv: Implement FEAT_XNX and FEAT_HAF Marc Zyngier

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=aRtlvNj9yMZoVb9g@kernel.org \
    --to=oupton@kernel.org \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=suzuki.poulose@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 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.