[PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode

[PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode

[fangyu.yu]

From: Fangyu Yu <fangyu.yu@linux.alibaba.com>

Currently, HGATP mode uses the maximum value detected by the hardware
but often such a wide GPA is unnecessary, just as a host sometimes
doesn't need sv57.
It's likely that no additional parameters (like no5lvl and no4lvl) are
needed, aligning HGATP mode to SATP mode should meet the requirements
of most scenarios.

Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com>
---
 arch/riscv/kvm/gstage.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/kvm/gstage.c b/arch/riscv/kvm/gstage.c
index b67d60d722c2..bff80c80ead3 100644
--- a/arch/riscv/kvm/gstage.c
+++ b/arch/riscv/kvm/gstage.c
@@ -320,7 +320,6 @@ void __init kvm_riscv_gstage_mode_detect(void)
 	csr_write(CSR_HGATP, HGATP_MODE_SV57X4 << HGATP_MODE_SHIFT);
 	if ((csr_read(CSR_HGATP) >> HGATP_MODE_SHIFT) == HGATP_MODE_SV57X4) {
 		kvm_riscv_gstage_mode = HGATP_MODE_SV57X4;
-		kvm_riscv_gstage_pgd_levels = 5;
 		goto done;
 	}
 
@@ -328,7 +327,6 @@ void __init kvm_riscv_gstage_mode_detect(void)
 	csr_write(CSR_HGATP, HGATP_MODE_SV48X4 << HGATP_MODE_SHIFT);
 	if ((csr_read(CSR_HGATP) >> HGATP_MODE_SHIFT) == HGATP_MODE_SV48X4) {
 		kvm_riscv_gstage_mode = HGATP_MODE_SV48X4;
-		kvm_riscv_gstage_pgd_levels = 4;
 		goto done;
 	}
 
@@ -336,7 +334,6 @@ void __init kvm_riscv_gstage_mode_detect(void)
 	csr_write(CSR_HGATP, HGATP_MODE_SV39X4 << HGATP_MODE_SHIFT);
 	if ((csr_read(CSR_HGATP) >> HGATP_MODE_SHIFT) == HGATP_MODE_SV39X4) {
 		kvm_riscv_gstage_mode = HGATP_MODE_SV39X4;
-		kvm_riscv_gstage_pgd_levels = 3;
 		goto done;
 	}
 #else /* CONFIG_32BIT */
@@ -354,6 +351,10 @@ void __init kvm_riscv_gstage_mode_detect(void)
 	kvm_riscv_gstage_pgd_levels = 0;
 
 done:
+#ifdef CONFIG_64BIT
+	kvm_riscv_gstage_mode = min(satp_mode >> SATP_MODE_SHIFT, kvm_riscv_gstage_mode);
+	kvm_riscv_gstage_pgd_levels = kvm_riscv_gstage_mode - HGATP_MODE_SV39X4 + 3;
+#endif
 	csr_write(CSR_HGATP, 0);
 	kvm_riscv_local_hfence_gvma_all();
 }
-- 
2.50.1

Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode

[Guo Ren]

On Sat, Nov 22, 2025 at 3:50 PM <fangyu.yu@linux.alibaba.com> wrote:
>
> From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
>
> Currently, HGATP mode uses the maximum value detected by the hardware
> but often such a wide GPA is unnecessary, just as a host sometimes
> doesn't need sv57.
> It's likely that no additional parameters (like no5lvl and no4lvl) are
> needed, aligning HGATP mode to SATP mode should meet the requirements
> of most scenarios.
Yes, no5/4lvl is not clear about satp or hgatp. So, covering HGPATP is
reasonable.

Acked-by: Guo Ren <guoren@kernel.org>

>
> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com>
> ---
>  arch/riscv/kvm/gstage.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/riscv/kvm/gstage.c b/arch/riscv/kvm/gstage.c
> index b67d60d722c2..bff80c80ead3 100644
> --- a/arch/riscv/kvm/gstage.c
> +++ b/arch/riscv/kvm/gstage.c
> @@ -320,7 +320,6 @@ void __init kvm_riscv_gstage_mode_detect(void)
>         csr_write(CSR_HGATP, HGATP_MODE_SV57X4 << HGATP_MODE_SHIFT);
>         if ((csr_read(CSR_HGATP) >> HGATP_MODE_SHIFT) == HGATP_MODE_SV57X4) {
>                 kvm_riscv_gstage_mode = HGATP_MODE_SV57X4;
> -               kvm_riscv_gstage_pgd_levels = 5;
>                 goto done;
>         }
>
> @@ -328,7 +327,6 @@ void __init kvm_riscv_gstage_mode_detect(void)
>         csr_write(CSR_HGATP, HGATP_MODE_SV48X4 << HGATP_MODE_SHIFT);
>         if ((csr_read(CSR_HGATP) >> HGATP_MODE_SHIFT) == HGATP_MODE_SV48X4) {
>                 kvm_riscv_gstage_mode = HGATP_MODE_SV48X4;
> -               kvm_riscv_gstage_pgd_levels = 4;
>                 goto done;
>         }
>
> @@ -336,7 +334,6 @@ void __init kvm_riscv_gstage_mode_detect(void)
>         csr_write(CSR_HGATP, HGATP_MODE_SV39X4 << HGATP_MODE_SHIFT);
>         if ((csr_read(CSR_HGATP) >> HGATP_MODE_SHIFT) == HGATP_MODE_SV39X4) {
>                 kvm_riscv_gstage_mode = HGATP_MODE_SV39X4;
> -               kvm_riscv_gstage_pgd_levels = 3;
>                 goto done;
>         }
>  #else /* CONFIG_32BIT */
> @@ -354,6 +351,10 @@ void __init kvm_riscv_gstage_mode_detect(void)
>         kvm_riscv_gstage_pgd_levels = 0;
>
>  done:
> +#ifdef CONFIG_64BIT
> +       kvm_riscv_gstage_mode = min(satp_mode >> SATP_MODE_SHIFT, kvm_riscv_gstage_mode);
It's out of the no5/4lvl scope, because we lose (hs-mode)satp=sv39 +
hgatp=sv48x4 combination.

How about re-parsing no5/4lvl parameters?

> +       kvm_riscv_gstage_pgd_levels = kvm_riscv_gstage_mode - HGATP_MODE_SV39X4 + 3;
> +#endif
>         csr_write(CSR_HGATP, 0);
>         kvm_riscv_local_hfence_gvma_all();
>  }
> --
> 2.50.1
>


-- 
Best Regards
 Guo Ren

Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode

[Andrew Jones]

On Sun, Nov 23, 2025 at 10:33:19AM +0800, Guo Ren wrote:
> On Sat, Nov 22, 2025 at 3:50 PM <fangyu.yu@linux.alibaba.com> wrote:
> >
> > From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
> >
> > Currently, HGATP mode uses the maximum value detected by the hardware
> > but often such a wide GPA is unnecessary, just as a host sometimes
> > doesn't need sv57.
> > It's likely that no additional parameters (like no5lvl and no4lvl) are
> > needed, aligning HGATP mode to SATP mode should meet the requirements
> > of most scenarios.
> Yes, no5/4lvl is not clear about satp or hgatp. So, covering HGPATP is
> reasonable.

The documentation should be improved, but I don't think we want to state
that these parameters apply to both s- and g-stage. If we need parameters
to dictate KVM behavior (g-stage management), then we should add KVM
module parameters.

Thanks,
drew

Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode

[fangyu.yu]

>> On Sat, Nov 22, 2025 at 3:50 PM <fangyu.yu@linux.alibaba.com> wrote:
>> >
>> > From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
>> >
>> > Currently, HGATP mode uses the maximum value detected by the hardware
>> > but often such a wide GPA is unnecessary, just as a host sometimes
>> > doesn't need sv57.
>> > It's likely that no additional parameters (like no5lvl and no4lvl) are
>> > needed, aligning HGATP mode to SATP mode should meet the requirements
>> > of most scenarios.
>> Yes, no5/4lvl is not clear about satp or hgatp. So, covering HGPATP is
>> reasonable.
>
>The documentation should be improved, but I don't think we want to state
>that these parameters apply to both s- and g-stage. If we need parameters
>to dictate KVM behavior (g-stage management), then we should add KVM
>module parameters.

Right, adding new parameters for g-stage management is clear.

Or we could discuss this topic, from a virtual machine perspective,
it may not be necessary to provide all hardware configuration
combinations. For example, when SATP is configured as sv48,
configuring HGATP as sv57*4 is not very meaningful, Because the
VM cannot actually use more than 48 bits of GPA range.

Thanks,
Fangyu
>Thanks,
>drew

Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode

[Radim Krčmář]

2025-11-25T22:18:11+08:00, <fangyu.yu@linux.alibaba.com>:
>>> On Sat, Nov 22, 2025 at 3:50 PM <fangyu.yu@linux.alibaba.com> wrote:
>>> >
>>> > From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
>>> >
>>> > Currently, HGATP mode uses the maximum value detected by the hardware
>>> > but often such a wide GPA is unnecessary, just as a host sometimes
>>> > doesn't need sv57.
>>> > It's likely that no additional parameters (like no5lvl and no4lvl) are
>>> > needed, aligning HGATP mode to SATP mode should meet the requirements
>>> > of most scenarios.
>>> Yes, no5/4lvl is not clear about satp or hgatp. So, covering HGPATP is
>>> reasonable.
>>
>>The documentation should be improved, but I don't think we want to state
>>that these parameters apply to both s- and g-stage. If we need parameters
>>to dictate KVM behavior (g-stage management), then we should add KVM
>>module parameters.
>
> Right, adding new parameters for g-stage management is clear.
>
> Or we could discuss this topic, from a virtual machine perspective,
> it may not be necessary to provide all hardware configuration
> combinations. For example, when SATP is configured as sv48,
> configuring HGATP as sv57*4 is not very meaningful, Because the
> VM cannot actually use more than 48 bits of GPA range.

The choice of hgatp mode depends on how users configure guest's memory
map, regardless of what satp or vsatp modes are.
(All RV64 SvXY modes map XY bit VA to 56 bit PA.)

If the machine model maps memory with set bit 55, then KVM needs to
configure Sv57x4, and if nothing is mapped above 2 TiB, then KVM is
completely fine with Sv39x4.

A module parameter works, but I think it would be nicer to set the hgatp
mode per-VM, because most VMs could use the efficient Sv39x4, while it's
not a good idea to pick it as the default.
I think KVM has enough information to do it automatically (and without
too much complexity) by starting with Sv39x4, and expanding as needed.

Thanks.

Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode

[fangyu.yu]

>>>> On Sat, Nov 22, 2025 at 3:50 PM <fangyu.yu@linux.alibaba.com> wrote:
>>>> >
>>>> > From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
>>>> >
>>>> > Currently, HGATP mode uses the maximum value detected by the hardware
>>>> > but often such a wide GPA is unnecessary, just as a host sometimes
>>>> > doesn't need sv57.
>>>> > It's likely that no additional parameters (like no5lvl and no4lvl) are
>>>> > needed, aligning HGATP mode to SATP mode should meet the requirements
>>>> > of most scenarios.
>>>> Yes, no5/4lvl is not clear about satp or hgatp. So, covering HGPATP is
>>>> reasonable.
>>>
>>>The documentation should be improved, but I don't think we want to state
>>>that these parameters apply to both s- and g-stage. If we need parameters
>>>to dictate KVM behavior (g-stage management), then we should add KVM
>>>module parameters.
>>
>> Right, adding new parameters for g-stage management is clear.
>>
>> Or we could discuss this topic, from a virtual machine perspective,
>> it may not be necessary to provide all hardware configuration
>> combinations. For example, when SATP is configured as sv48,
>> configuring HGATP as sv57*4 is not very meaningful, Because the
>> VM cannot actually use more than 48 bits of GPA range.
>
>The choice of hgatp mode depends on how users configure guest's memory
>map, regardless of what satp or vsatp modes are.
>(All RV64 SvXY modes map XY bit VA to 56 bit PA.)
>
>If the machine model maps memory with set bit 55, then KVM needs to
>configure Sv57x4, and if nothing is mapped above 2 TiB, then KVM is
>completely fine with Sv39x4.
>
>A module parameter works, but I think it would be nicer to set the hgatp
>mode per-VM, because most VMs could use the efficient Sv39x4, while it's
>not a good idea to pick it as the default.
>I think KVM has enough information to do it automatically (and without
>too much complexity) by starting with Sv39x4, and expanding as needed.
>

It does seem more reasonable to select the HGATP mode for each VM based
on the actual required GPA range.
I will send an updated patch based on this suggestion.

Thanks,
Fangyu

Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode

[Anup Patel]

On Thu, Nov 27, 2025 at 7:09 AM Guo Ren <guoren@kernel.org> wrote:
>
>
>
> On Wed, Nov 26, 2025 at 2:16 AM Radim Krčmář <rkrcmar@ventanamicro.com> wrote:
>>
>> 2025-11-25T22:18:11+08:00, <fangyu.yu@linux.alibaba.com>:
>> >>> On Sat, Nov 22, 2025 at 3:50 PM <fangyu.yu@linux.alibaba.com> wrote:
>> >>> >
>> >>> > From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
>> >>> >
>> >>> > Currently, HGATP mode uses the maximum value detected by the hardware
>> >>> > but often such a wide GPA is unnecessary, just as a host sometimes
>> >>> > doesn't need sv57.
>> >>> > It's likely that no additional parameters (like no5lvl and no4lvl) are
>> >>> > needed, aligning HGATP mode to SATP mode should meet the requirements
>> >>> > of most scenarios.
>> >>> Yes, no5/4lvl is not clear about satp or hgatp. So, covering HGPATP is
>> >>> reasonable.
>> >>
>> >>The documentation should be improved, but I don't think we want to state
>> >>that these parameters apply to both s- and g-stage. If we need parameters
>> >>to dictate KVM behavior (g-stage management), then we should add KVM
>> >>module parameters.
>> >
>> > Right, adding new parameters for g-stage management is clear.
>> >
>> > Or we could discuss this topic, from a virtual machine perspective,
>> > it may not be necessary to provide all hardware configuration
>> > combinations. For example, when SATP is configured as sv48,
>> > configuring HGATP as sv57*4 is not very meaningful, Because the
>> > VM cannot actually use more than 48 bits of GPA range.
>>
>> The choice of hgatp mode depends on how users configure guest's memory
>> map, regardless of what satp or vsatp modes are.
>> (All RV64 SvXY modes map XY bit VA to 56 bit PA.)
>>
>> If the machine model maps memory with set bit 55, then KVM needs to
>> configure Sv57x4, and if nothing is mapped above 2 TiB, then KVM is
>> completely fine with Sv39x4.
>>
>> A module parameter works, but I think it would be nicer to set the hgatp
>> mode per-VM, because most VMs could use the efficient Sv39x4, while it's
>> not a good idea to pick it as the default.
>> I think KVM has enough information to do it automatically (and without
>> too much complexity) by starting with Sv39x4, and expanding as needed.
>
> Good point; if only a 128GB GPA memory region is needed, there is no need for Sv57x4, which costs PTW cycles.
>
> So, the detection should start from Sv39x4 to Sv57x4 with the guest memory size.
>

NACK to the approach of detecting backwards.

HGATP mode is a per-VM attribute hence it makes sense
to define a VM-level KVM_CAP_RISC_xyz for this purpose.
The default behaviour should be use highest HGATP mode
unless KVM user-space changes the KVM_CAP_RISC_xyz
setting.

---
Anup