linux-kernel - Re: Re: [PATCH v4 2/4] RISC-V: KVM: Detect and expose supported HGATP G-stage modes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20260203142422.99110-1-fangyu.yu@linux.alibaba.com>
Date: Tue,  3 Feb 2026 22:24:22 +0800
From: fangyu.yu@...ux.alibaba.com
To: radim.krcmar@....qualcomm.com
Cc: ajones@...tanamicro.com,
	alex@...ti.fr,
	andrew.jones@....qualcomm.com,
	anup@...infault.org,
	aou@...s.berkeley.edu,
	atish.patra@...ux.dev,
	corbet@....net,
	fangyu.yu@...ux.alibaba.com,
	guoren@...nel.org,
	kvm-riscv@...ts.infradead.org,
	kvm@...r.kernel.org,
	linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-riscv@...ts.infradead.org,
	palmer@...belt.com,
	pbonzini@...hat.com,
	pjw@...nel.org,
	rkrcmar@...tanamicro.com
Subject: Re: Re: [PATCH v4 2/4] RISC-V: KVM: Detect and expose supported HGATP G-stage modes

>> From: Fangyu Yu <fangyu.yu@...ux.alibaba.com>
>>
>> Extend kvm_riscv_gstage_mode_detect() to probe all HGATP.MODE values
>> supported by the host and record them in a bitmask. Keep tracking the
>> maximum supported G-stage page table level for existing internal users.
>>
>> Also provide lightweight helpers to retrieve the supported-mode bitmask
>> and validate a requested HGATP.MODE against it.
>>
>> Signed-off-by: Fangyu Yu <fangyu.yu@...ux.alibaba.com>
>> ---
>> diff --git a/arch/riscv/include/asm/kvm_gstage.h b/arch/riscv/include/asm/kvm_gstage.h
>> @@ -75,4 +76,40 @@ void kvm_riscv_gstage_wp_range(struct kvm_gstage *gstage, gpa_t start, gpa_t end
>> +enum kvm_riscv_hgatp_mode_bit {
>> +	HGATP_MODE_SV39X4_BIT = 0,
>> +	HGATP_MODE_SV48X4_BIT = 1,
>> +	HGATP_MODE_SV57X4_BIT = 2,
>
>I think it's a bit awkward to pass 9 when selecting the hgatp mode, but
>then look for bit 0 when detecting it...
>Why not to use the RVI defined values for this UABI as well?
>
>There are only 16 possible hgatp.mode values, so we're fine storing them
>in a bitmap even on RV32.

I think this is a good point.

Using logical bits 0/1/2 is indeed less intuitive than testing
BIT(HGATP_MODE_SV39X4) when userspace passes the architectural HGATP.MODE
encoding.

However, if we use “HGATP.MODE encoding as bit index”, we need to export
those encodings to userspace. Today HGATP_MODE_* are not part of the
UAPI, so userspace would need to hardcode magic numbers.

So if we go with this approach, I’ll add UAPI definitions for the HGATP
mode encodings (e.g. #define KVM_RISCV_HGATP_MODE_SV39X4_BIT  8, etc.) and
then define the returned bitmask as BIT(mode).

>
>Thanks.
>
Thanks,
Fangyu