Received-SPF: pass (google.com: domain of linux-kernel+bounces-51029-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Feedback-ID: i84414492:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61
Precedence: bulk
MIME-Version: 1.0
Message-Id: <5657c211-531b-4890-8c52-182b7b4eae7c@app.fastmail.com>
In-Reply-To: <701d3350-93d3-4235-aaf7-04c6492420a7@rivosinc.com>
References: <20240201140319.360088-1-cleger@rivosinc.com>
 <ZbxUUsKdKIPI8Fb/@ghost> <701d3350-93d3-4235-aaf7-04c6492420a7@rivosinc.com>
Date: Sat, 03 Feb 2024 05:40:06 -0500
From: "Stefan O'Rear" <sorear@fastmail.com>
To: =?UTF-8?Q?Cl=C3=A9ment_L=C3=A9ger?= <cleger@rivosinc.com>,
 "Charlie Jenkins" <charlie@rivosinc.com>
Cc: "Jonathan Corbet" <corbet@lwn.net>,
 "Paul Walmsley" <paul.walmsley@sifive.com>,
 "Palmer Dabbelt" <palmer@dabbelt.com>, "Albert Ou" <aou@eecs.berkeley.edu>,
 linux-doc@vger.kernel.org, linux-riscv@lists.infradead.org,
 linux-kernel@vger.kernel.org, "Robin Ehn" <rehn@rivosinc.com>
Subject: Re: [PATCH] riscv: hwprobe: export VA_BITS
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 2, 2024, at 3:22 AM, Cl=C3=A9ment L=C3=A9ger wrote:
> On 02/02/2024 03:32, Charlie Jenkins wrote:
>> On Thu, Feb 01, 2024 at 03:02:45PM +0100, Cl=C3=A9ment L=C3=A9ger wro=
te:
>>> Some userspace applications (OpenJDK for instance) uses the free bits
>>> in pointers to insert additional information for their own logic.
>>> Currently they rely on parsing /proc/cpuinfo to obtain the current v=
alue
>>> of virtual address used bits [1]. Exporting VA_BITS through hwprobe =
will
>>> allow for a more stable interface to be used.
>>=20
>> mmap already supports this without a need for applications to know the
>> underlying hardware. If a hint address is passed into mmap, it will n=
ever
>> return an address that uses more bits than the hint address. I design=
ed
>> it that way so that something like this wasn't necessary.
>
> Ok even though probing this kind of thing is probably not what mmap is
> meant to do. IMHO, probing this through the regular hwprobe interface =
is
> probably more coherent but maybe Robin (which needs this information)
> can rely on that.

Both of these are useful, separately and in conjunction.

hwprobe allows applications which can adapt to different VA sizes to lea=
rn
which is in use prior to allocating memory.

mmap hints allow applications which require a fixed limit on the VA size=
 to
express that limit at the point of requirement, the hint can be set base=
d on
the hwprobe result to explicitly indicate its use.

-s

> Cl=C3=A9ment
>
>>=20
>> - Charlie
>>=20
>>>
>>> Link: https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/=
linux_riscv/vm_version_linux_riscv.cpp#L171 [1]
>>> Signed-off-by: Cl=C3=A9ment L=C3=A9ger <cleger@rivosinc.com>
>>>
>>> ---
>>>  Documentation/arch/riscv/hwprobe.rst  | 3 +++
>>>  arch/riscv/include/asm/hwprobe.h      | 2 +-
>>>  arch/riscv/include/uapi/asm/hwprobe.h | 1 +
>>>  arch/riscv/kernel/sys_hwprobe.c       | 3 +++
>>>  4 files changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/ar=
ch/riscv/hwprobe.rst
>>> index b2bcc9eed9aa..6f198c6ed4f0 100644
>>> --- a/Documentation/arch/riscv/hwprobe.rst
>>> +++ b/Documentation/arch/riscv/hwprobe.rst
>>> @@ -210,3 +210,6 @@ The following keys are defined:
>>> =20
>>>  * :c:macro:`RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`: An unsigned int w=
hich
>>>    represents the size of the Zicboz block in bytes.
>>> +
>>> +* :c:macro:`RISCV_HWPROBE_KEY_VA_BITS`: An unsigned long which
>>> +  represent the number of bits used to store virtual addresses.
>>> diff --git a/arch/riscv/include/asm/hwprobe.h b/arch/riscv/include/a=
sm/hwprobe.h
>>> index 630507dff5ea..150a9877b0af 100644
>>> --- a/arch/riscv/include/asm/hwprobe.h
>>> +++ b/arch/riscv/include/asm/hwprobe.h
>>> @@ -8,7 +8,7 @@
>>> =20
>>>  #include <uapi/asm/hwprobe.h>
>>> =20
>>> -#define RISCV_HWPROBE_MAX_KEY 6
>>> +#define RISCV_HWPROBE_MAX_KEY 7
>>> =20
>>>  static inline bool riscv_hwprobe_key_is_valid(__s64 key)
>>>  {
>>> diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/incl=
ude/uapi/asm/hwprobe.h
>>> index 9f2a8e3ff204..2a5006cddb7b 100644
>>> --- a/arch/riscv/include/uapi/asm/hwprobe.h
>>> +++ b/arch/riscv/include/uapi/asm/hwprobe.h
>>> @@ -67,6 +67,7 @@ struct riscv_hwprobe {
>>>  #define		RISCV_HWPROBE_MISALIGNED_UNSUPPORTED	(4 << 0)
>>>  #define		RISCV_HWPROBE_MISALIGNED_MASK		(7 << 0)
>>>  #define RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE	6
>>> +#define RISCV_HWPROBE_KEY_VA_BITS		7
>>>  /* Increase RISCV_HWPROBE_MAX_KEY when adding items. */
>>> =20
>>>  /* Flags */
>>> diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys=
_hwprobe.c
>>> index a7c56b41efd2..328435836e36 100644
>>> --- a/arch/riscv/kernel/sys_hwprobe.c
>>> +++ b/arch/riscv/kernel/sys_hwprobe.c
>>> @@ -202,6 +202,9 @@ static void hwprobe_one_pair(struct riscv_hwprob=
e *pair,
>>>  		if (hwprobe_ext0_has(cpus, RISCV_HWPROBE_EXT_ZICBOZ))
>>>  			pair->value =3D riscv_cboz_block_size;
>>>  		break;
>>> +	case RISCV_HWPROBE_KEY_VA_BITS:
>>> +		pair->value =3D VA_BITS;
>>> +		break;
>>> =20
>>>  	/*
>>>  	 * For forward compatibility, unknown keys don't fail the whole
>>> --=20
>>> 2.43.0
>>>
>>>
>>> _______________________________________________
>>> linux-riscv mailing list
>>> linux-riscv@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv