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

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

Posted by fangyu.yu@linux.alibaba.com 1 week, 2 days ago

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

Posted by Guo Ren 1 week, 1 day ago

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

Posted by Andrew Jones 1 week ago

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

Posted by fangyu.yu@linux.alibaba.com 6 days, 10 hours ago

>> 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

Posted by Radim Krčmář 6 days, 6 hours ago

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

Posted by fangyu.yu@linux.alibaba.com 2 days, 15 hours ago

>>>> 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