Received-SPF: pass (google.com: domain of linux-kernel+bounces-159776-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Fri, 26 Apr 2024 11:22:04 +0200
From: Claudio Imbrenda <imbrenda@linux.ibm.com>
To: Heiko Carstens <hca@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
        gor@linux.ibm.com, agordeev@linux.ibm.com, svens@linux.ibm.com,
        gerald.schaefer@linux.ibm.com, borntraeger@de.ibm.com
Subject: Re: [PATCH v1 2/2] s390/pgtable: introduce
 _REGION3_ENTRY_HARDWARE_BITS_LARGE
Message-ID: <20240426112204.10c00d33@p-imbrenda.boeblingen.de.ibm.com>
In-Reply-To: <20240426085714.8950-F-hca@linux.ibm.com>
References: <20240425130555.73132-1-imbrenda@linux.ibm.com>
	<20240425130555.73132-3-imbrenda@linux.ibm.com>
	<20240426085714.8950-F-hca@linux.ibm.com>
Organization: IBM
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri, 26 Apr 2024 10:57:14 +0200
Heiko Carstens <hca@linux.ibm.com> wrote:

> On Thu, Apr 25, 2024 at 03:05:55PM +0200, Claudio Imbrenda wrote:
> > For completeness, introduce _REGION3_ENTRY_HARDWARE_BITS_LARGE,
> > containing the hardware bits used for large puds.
> > 
> > Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
> > ---
> >  arch/s390/include/asm/pgtable.h | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
> > index 3da2995fd196..5c0f840eee2a 100644
> > --- a/arch/s390/include/asm/pgtable.h
> > +++ b/arch/s390/include/asm/pgtable.h
> > @@ -262,6 +262,7 @@ static inline int is_module_addr(void *addr)
> >  #define _REGION3_ENTRY		(_REGION_ENTRY_TYPE_R3 | _REGION_ENTRY_LENGTH)
> >  #define _REGION3_ENTRY_EMPTY	(_REGION_ENTRY_TYPE_R3 | _REGION_ENTRY_INVALID)
> >  
> > +#define _REGION3_ENTRY_HARDWARE_BITS_LARGE	0xffffffff8000073cUL  
> 
> _REGION_ENTRY_HARDWARE_BITS is missing too. :)

right, I will fix it

> 
> And this definition also raises the question if the definition of
> _SEGMENT_ENTRY_HARDWARE_BITS_LARGE should be changed so it also includes
> the table type bits, which it probably should.

tbh I agree

> 
> These masks are really a bit randomly defined and assume that the
> ACCF-Validity control bit is never set, and therefore the ACC bitfield can
> be assumed to be software bits (and they are used as such for format 1
> segment table entries).
> 
> But the ACCF bit is also a hardware bit in any case... oh well.

probably the ACCF bit should also be marked as hardware bit (I had
actually thought about it, but we don't do it for segments and I wanted
it to be consistent)

I'll send a v2 with:

segment table type bits
ACCF bit (both for segments and region3
_REGION3_ENTRY_HARDWARE_BITS