All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Mark Rutland <mark.rutland@arm.com>,
	Marc Zyngier <maz@kernel.org>
Subject: Re: [PATCH] irqchip/gic-v5: Fix GIC CDEOI instruction encoding
Date: Mon, 6 Oct 2025 16:24:18 +0100	[thread overview]
Message-ID: <aOPfIgrxZaqzu-7s@arm.com> (raw)
In-Reply-To: <aOPZqM2xGIrPJH/d@lpieralisi>

On Mon, Oct 06, 2025 at 05:00:56PM +0200, Lorenzo Pieralisi wrote:
> On Mon, Oct 06, 2025 at 02:30:04PM +0100, Catalin Marinas wrote:
> > On Mon, Oct 06, 2025 at 12:07:58PM +0200, Lorenzo Pieralisi wrote:
> > > diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> > > index 6455db1b54fd..6cf8c46ddde5 100644
> > > --- a/arch/arm64/include/asm/sysreg.h
> > > +++ b/arch/arm64/include/asm/sysreg.h
> > > @@ -113,14 +113,14 @@
> > >  /* Register-based PAN access, for save/restore purposes */
> > >  #define SYS_PSTATE_PAN			sys_reg(3, 0, 4, 2, 3)
> > >  
> > > -#define __SYS_BARRIER_INSN(op0, op1, CRn, CRm, op2, Rt)			\
> > > +#define __SYS_INSN(op0, op1, CRn, CRm, op2, Rt)				\
> > >  	__emit_inst(0xd5000000					|	\
> > >  		    sys_insn((op0), (op1), (CRn), (CRm), (op2))	|	\
> > >  		    ((Rt) & 0x1f))
> > >  
> > > -#define SB_BARRIER_INSN			__SYS_BARRIER_INSN(0, 3, 3, 0, 7, 31)
> > > -#define GSB_SYS_BARRIER_INSN		__SYS_BARRIER_INSN(1, 0, 12, 0, 0, 31)
> > > -#define GSB_ACK_BARRIER_INSN		__SYS_BARRIER_INSN(1, 0, 12, 0, 1, 31)
> > > +#define SB_BARRIER_INSN			__SYS_INSN(0, 3, 3, 0, 7, 31)
> > > +#define GSB_SYS_BARRIER_INSN		__SYS_INSN(1, 0, 12, 0, 0, 31)
> > > +#define GSB_ACK_BARRIER_INSN		__SYS_INSN(1, 0, 12, 0, 1, 31)
> > >  
> > >  /* Data cache zero operations */
> > >  #define SYS_DC_ISW			sys_insn(1, 0, 7, 6, 2)
> > > @@ -1075,7 +1075,6 @@
> > >  #define GICV5_OP_GIC_CDDIS		sys_insn(1, 0, 12, 1, 0)
> > >  #define GICV5_OP_GIC_CDHM		sys_insn(1, 0, 12, 2, 1)
> > >  #define GICV5_OP_GIC_CDEN		sys_insn(1, 0, 12, 1, 1)
> > > -#define GICV5_OP_GIC_CDEOI		sys_insn(1, 0, 12, 1, 7)
> > >  #define GICV5_OP_GIC_CDPEND		sys_insn(1, 0, 12, 1, 4)
> > >  #define GICV5_OP_GIC_CDPRI		sys_insn(1, 0, 12, 1, 2)
> > >  #define GICV5_OP_GIC_CDRCFG		sys_insn(1, 0, 12, 1, 5)
> > > @@ -1129,6 +1128,17 @@
> > >  #define gicr_insn(insn)			read_sysreg_s(GICV5_OP_GICR_##insn)
> > >  #define gic_insn(v, insn)		write_sysreg_s(v, GICV5_OP_GIC_##insn)
> > >  
> > > +/*
> > > + * GIC CDEOI encoding requires Rt to be 0b11111.
> > > + * gic_insn() with an immediate value of 0 cannot be used to encode it
> > > + * because some compilers do not follow asm inline constraints in
> > > + * write_sysreg_s() to turn an immediate 0 value into an XZR as
> > > + * MSR source register.
> > > + * Use __SYS_INSN to specify its precise encoding explicitly.
> > > + */
> > > +#define GICV5_CDEOI_INSN		__SYS_INSN(1, 0, 12, 1, 7, 31)
> > > +#define gic_cdeoi()			asm volatile(GICV5_CDEOI_INSN)
> > 
> > Would something like this work? Completely untested (and build still
> > going):
> 
> I tested the GIC CDEOI code generated with GCC/LLVM and it works.
> 
> My only remark there is that even as the code in mainline stands with
> GCC, it is not very clear that we rely on implicit XZR generation to
> make sure the instruction encoding generated is correct - it looks
> like a bit of a stretch to reuse a sysreg write with immediate value == 0
> to generate a system instruction write with Rt == 0b11111, it works
> but it is a bit opaque or at least not straighforward to grok.
> 
> Obviously the patch below improves LLVM code generation too in the process.
> 
> I don't know what's best - I admit I am on the fence on this one.

My concern is other cases where we may rely on this, so we might as well
go with a generic approach than fixing each case individually. If that's
the only case, I'll leave it to you and Marc do decide whichever you
prefer.

I assume we don't need this for write_sysreg(), those are accesses to
named registers gas already knows about, not used to generate new
instructions.

-- 
Catalin


  reply	other threads:[~2025-10-06 15:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-06 10:07 [PATCH] irqchip/gic-v5: Fix GIC CDEOI instruction encoding Lorenzo Pieralisi
2025-10-06 13:30 ` Catalin Marinas
2025-10-06 15:00   ` Lorenzo Pieralisi
2025-10-06 15:24     ` Catalin Marinas [this message]
2025-10-07  8:58       ` Lorenzo Pieralisi
2025-10-07 10:16         ` Catalin Marinas
2025-10-06 15:07   ` 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=aOPfIgrxZaqzu-7s@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=sascha.bischoff@arm.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    /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.