Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 25 Nov 2020 13:26:17 +0000
From:   David Brazdil <dbrazdil@google.com>
To:     Marc Zyngier <maz@kernel.org>
Cc:     kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, James Morse <james.morse@arm.com>,
        Julien Thierry <julien.thierry.kdev@gmail.com>,
        Suzuki K Poulose <suzuki.poulose@arm.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>, Dennis Zhou <dennis@kernel.org>,
        Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@linux.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
        Quentin Perret <qperret@google.com>,
        Andrew Scull <ascull@google.com>,
        Andrew Walbran <qwandor@google.com>, kernel-team@android.com
Subject: Re: [PATCH v2 04/24] arm64: Move MAIR_EL1_SET to asm/memory.h
Message-ID: <20201125132617.qf6vd752dtfasyi7@google.com>
References: <20201116204318.63987-1-dbrazdil@google.com>
 <20201116204318.63987-5-dbrazdil@google.com>
 <87mtz85geh.wl-maz@kernel.org>
 <20201125103137.iml7mqpzhylldvqy@google.com>
 <e6c9184c6ee986d134625932b4fa8e89@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e6c9184c6ee986d134625932b4fa8e89@kernel.org>
Precedence: bulk

> > > > +/*
> > > > + * Memory types available.
> > > > + *
> > > > + * IMPORTANT: MT_NORMAL must be index 0 since vm_get_page_prot() may 'or' in
> > > > + *	      the MT_NORMAL_TAGGED memory type for PROT_MTE mappings. Note
> > > > + *	      that protection_map[] only contains MT_NORMAL attributes.
> > > > + */
> > > > +#define MT_NORMAL		0
> > > > +#define MT_NORMAL_TAGGED	1
> > > > +#define MT_NORMAL_NC		2
> > > > +#define MT_NORMAL_WT		3
> > > > +#define MT_DEVICE_nGnRnE	4
> > > > +#define MT_DEVICE_nGnRE		5
> > > > +#define MT_DEVICE_GRE		6
> > > > +
> > > > +/*
> > > > + * Default MAIR_ELx. MT_NORMAL_TAGGED is initially mapped as Normal memory and
> > > > + * changed during __cpu_setup to Normal Tagged if the system supports MTE.
> > > > + */
> > > > +#define MAIR_ELx_SET							\
> > > > +	(MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) |	\
> > > > +	 MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRE, MT_DEVICE_nGnRE) |	\
> > > > +	 MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) |		\
> > > > +	 MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) |		\
> > > > +	 MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) |			\
> > > > +	 MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) |		\
> > > > +	 MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED))
> > > > +
> 
> Wait: You now have MAIR_ELx_SET defined at two locations. Surely that's
> one too many.
> 

Oops, told you I tried different things...

> > > >  /* id_aa64isar0 */
> > > >  #define ID_AA64ISAR0_RNDR_SHIFT		60
> > > >  #define ID_AA64ISAR0_TLB_SHIFT		56
> > > > @@ -992,6 +1020,7 @@
> > > >  /* Safe value for MPIDR_EL1: Bit31:RES1, Bit30:U:0, Bit24:MT:0 */
> > > >  #define SYS_MPIDR_SAFE_VAL	(BIT(31))
> > > >
> > > > +#ifndef LINKER_SCRIPT
> > > 
> > > This is terribly ugly. Why is this included by the linker script? Does
> > > it actually define __ASSEMBLY__?
> > 
> > vmlinux.lds.S includes memory.h for PAGE_SIZE. And yes, linker scripts
> > are
> > built with this rule:
> > 
> >       cmd_cpp_lds_S = $(CPP) $(cpp_flags) -P -U$(ARCH) \
> > 	                     -D__ASSEMBLY__ -DLINKER_SCRIPT -o $@ $<
> > 
> > I tried a few things and wasn't completely happy with any of them. I
> > think in
> > the previous spin you suggested moving this constant to sysreg.h. That
> > works
> > too but sysreg.h seems to have only architecture constants, memory.h
> > about a
> > Linux-specific configuration, so I wanted to keep it here.
> 
> MAIR_ELx_SET isn't really Linux specific. Or rather, not more specific than
> any of the other configurations we have. On the other hand, the S1 MT_*
> stuff
> is totally arbitrary, and does fit in memory.h, together with the rest of
> the indexes for the memory types.
> 
> I came up with the following patch on top of this series that seems to
> compile without issue.

That seems to have an implicit dependency of sysreg.h on memory.h, doesn't it?
I had it the other way round initially. I also tried including memory.h in
sysreg.h. That creates a circular dependency mmdebug.h -> bug.h -> ... ->
sysreg.h -> memory.h -> mmdebug.h. Pretty annoying. I could try to fix that,
or create a new header file... :(