linux-kernel - Re: Re: [PATCH v3 1/2] RISC-V: KVM: Support runtime configuration for per-VM's HGATP mode

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] [day] [month] [year] [list]

Message-Id: <20260131061238.52708-1-fangyu.yu@linux.alibaba.com>
Date: Sat, 31 Jan 2026 14:12:38 +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
Subject: Re: Re: [PATCH v3 1/2] RISC-V: KVM: Support runtime configuration for per-VM's HGATP mode

>>>> From: Fangyu Yu <fangyu.yu@...ux.alibaba.com>
>>>> -	kvm_info("using %s G-stage page table format\n", str);
>>>> +	kvm_info("Max G-stage page table format %s\n", str);
>>>
>>>Fun fact: the ISA doesn't define the same hierarchy for hgatp modes as
>>>it does for satp modes, so we could have just Sv57x4 and nothing below.
>>>
>>>We could do just with a code comment that we're assuming vendors will do
>>>better, but I'd rather not introduce more assumptions...
>>>I think the easiest would be to kvm_riscv_gstage_mode_detect() levels in
>>>reverse and stop on the first one that is not supported.
>>>(I'll reply with a patch later.)
>>
>> Please refer to the discussion here:
>> https://github.com/riscv/riscv-isa-manual/issues/2208
>> If Sv57x4 is implemented, then Sv48x4 and Sv39x4 must also be implemented.
>
>I don't think so, sadly, but we're mostly dealing with technicalities
>here.  As Andrew pointed out:
>
>  "The H extension itself does not impose this requirement, so
>  technically Sv57x4 without Sv48x4 conforms to the H extension spec."
>
>This means it's completely valid to support {Bare, Sv39x4, Sv57x4}.
>The RVA23 profile imposes additional constraints via Shgatpa:
>
>  "For each supported virtual memory scheme SvNN supported in satp, the
>  corresponding hgatp SvNNx4 mode must be supported.
>  The hgatp mode Bare must also be supported."
>
>The requirement only goes one way, so an RVA23 implementation with just
>{Bare, Sv39} in satp could support {Bare, Sv39x4, Sv57x4} in hgatp,
>because RVA23 nor ISA prevent Sv57x4 to be there.
>Not that I expect any sensible implementation to do this...
>
>Btw. do we target only RVA23 with KVM?

Thanks for the clarification.

No, I don't think we should assume we're targeting only RVA23 (or any
specific profile) with KVM. In general KVM should work with any
H-extension implementation that satisfies KVM’s requirements, without
depending on additional profile constraints unless explicitly stated.

Given that, relying on “if Sv57x4 exists then Sv48x4/Sv39x4 must exist”
would be an extra assumption. To avoid that, I’ll update the detection
logic to probe modes independently and record all supported modes (and
derive the max level from the resulting set by default).

Also, I will expose the full set of detected host-supported HGATP.MODE
values to userspace via KVM_CHECK_EXTENSION(KVM_CAP_RISCV_SET_HGATP_MODE)
as a bitmask, so userspace can select an appropriate mode.

>
>Thanks

Thanks,
Fangyu