* [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode @ 2025-11-22 7:50 ` fangyu.yu 0 siblings, 0 replies; 22+ messages in thread From: fangyu.yu @ 2025-11-22 7:50 UTC (permalink / raw) To: anup, atish.patra, pjw, palmer, aou, alex Cc: guoren, ajones, kvm, kvm-riscv, linux-riscv, linux-kernel, 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 -- kvm-riscv mailing list kvm-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kvm-riscv ^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode @ 2025-11-22 7:50 ` fangyu.yu 0 siblings, 0 replies; 22+ messages in thread From: fangyu.yu @ 2025-11-22 7:50 UTC (permalink / raw) To: anup, atish.patra, pjw, palmer, aou, alex Cc: guoren, ajones, kvm, kvm-riscv, linux-riscv, linux-kernel, 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode @ 2025-11-22 7:50 ` fangyu.yu 0 siblings, 0 replies; 22+ messages in thread From: fangyu.yu @ 2025-11-22 7:50 UTC (permalink / raw) To: anup, atish.patra, pjw, palmer, aou, alex Cc: guoren, ajones, kvm, kvm-riscv, linux-riscv, linux-kernel, 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 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode 2025-11-22 7:50 ` fangyu.yu (?) @ 2025-11-23 2:33 ` Guo Ren -1 siblings, 0 replies; 22+ messages in thread From: Guo Ren @ 2025-11-23 2:33 UTC (permalink / raw) To: fangyu.yu Cc: anup, atish.patra, pjw, palmer, aou, alex, ajones, kvm, kvm-riscv, linux-riscv, linux-kernel 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 -- kvm-riscv mailing list kvm-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kvm-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode @ 2025-11-23 2:33 ` Guo Ren 0 siblings, 0 replies; 22+ messages in thread From: Guo Ren @ 2025-11-23 2:33 UTC (permalink / raw) To: fangyu.yu Cc: anup, atish.patra, pjw, palmer, aou, alex, ajones, kvm, kvm-riscv, linux-riscv, linux-kernel 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode @ 2025-11-23 2:33 ` Guo Ren 0 siblings, 0 replies; 22+ messages in thread From: Guo Ren @ 2025-11-23 2:33 UTC (permalink / raw) To: fangyu.yu Cc: anup, atish.patra, pjw, palmer, aou, alex, ajones, kvm, kvm-riscv, linux-riscv, linux-kernel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode 2025-11-23 2:33 ` Guo Ren (?) @ 2025-11-24 15:27 ` Andrew Jones -1 siblings, 0 replies; 22+ messages in thread From: Andrew Jones @ 2025-11-24 15:27 UTC (permalink / raw) To: Guo Ren Cc: fangyu.yu, anup, atish.patra, pjw, palmer, aou, alex, kvm, kvm-riscv, linux-riscv, linux-kernel 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 -- kvm-riscv mailing list kvm-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kvm-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode @ 2025-11-24 15:27 ` Andrew Jones 0 siblings, 0 replies; 22+ messages in thread From: Andrew Jones @ 2025-11-24 15:27 UTC (permalink / raw) To: Guo Ren Cc: fangyu.yu, anup, atish.patra, pjw, palmer, aou, alex, kvm, kvm-riscv, linux-riscv, linux-kernel 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode @ 2025-11-24 15:27 ` Andrew Jones 0 siblings, 0 replies; 22+ messages in thread From: Andrew Jones @ 2025-11-24 15:27 UTC (permalink / raw) To: Guo Ren Cc: fangyu.yu, anup, atish.patra, pjw, palmer, aou, alex, kvm, kvm-riscv, linux-riscv, linux-kernel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode 2025-11-24 15:27 ` Andrew Jones (?) @ 2025-11-25 14:18 ` fangyu.yu -1 siblings, 0 replies; 22+ messages in thread From: fangyu.yu @ 2025-11-25 14:18 UTC (permalink / raw) To: ajones Cc: alex, anup, aou, atish.patra, fangyu.yu, guoren, kvm-riscv, kvm, linux-kernel, linux-riscv, palmer, pjw >> 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 -- kvm-riscv mailing list kvm-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kvm-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode @ 2025-11-25 14:18 ` fangyu.yu 0 siblings, 0 replies; 22+ messages in thread From: fangyu.yu @ 2025-11-25 14:18 UTC (permalink / raw) To: ajones Cc: alex, anup, aou, atish.patra, fangyu.yu, guoren, kvm-riscv, kvm, linux-kernel, linux-riscv, palmer, pjw >> 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode @ 2025-11-25 14:18 ` fangyu.yu 0 siblings, 0 replies; 22+ messages in thread From: fangyu.yu @ 2025-11-25 14:18 UTC (permalink / raw) To: ajones Cc: alex, anup, aou, atish.patra, fangyu.yu, guoren, kvm-riscv, kvm, linux-kernel, linux-riscv, palmer, pjw >> 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode 2025-11-25 14:18 ` fangyu.yu (?) @ 2025-11-25 18:15 ` Radim Krčmář -1 siblings, 0 replies; 22+ messages in thread From: Radim Krčmář @ 2025-11-25 18:15 UTC (permalink / raw) To: fangyu.yu, ajones Cc: alex, anup, aou, atish.patra, guoren, kvm-riscv, kvm, linux-kernel, linux-riscv, palmer, pjw, linux-riscv 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. -- kvm-riscv mailing list kvm-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kvm-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode @ 2025-11-25 18:15 ` Radim Krčmář 0 siblings, 0 replies; 22+ messages in thread From: Radim Krčmář @ 2025-11-25 18:15 UTC (permalink / raw) To: fangyu.yu, ajones Cc: alex, anup, aou, atish.patra, guoren, kvm-riscv, kvm, linux-kernel, linux-riscv, palmer, pjw, linux-riscv 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. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode @ 2025-11-25 18:15 ` Radim Krčmář 0 siblings, 0 replies; 22+ messages in thread From: Radim Krčmář @ 2025-11-25 18:15 UTC (permalink / raw) To: fangyu.yu, ajones Cc: alex, anup, aou, atish.patra, guoren, kvm-riscv, kvm, linux-kernel, linux-riscv, palmer, pjw, linux-riscv 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode 2025-11-25 18:15 ` Radim Krčmář (?) (?) @ 2025-11-27 1:39 ` Guo Ren 2025-12-03 6:08 ` Anup Patel -1 siblings, 1 reply; 22+ messages in thread From: Guo Ren @ 2025-11-27 1:39 UTC (permalink / raw) To: Radim Krčmář Cc: fangyu.yu, ajones, alex, anup, aou, atish.patra, kvm-riscv, kvm, linux-kernel, linux-riscv, palmer, pjw, linux-riscv [-- Attachment #1.1: Type: text/plain, Size: 2381 bytes --] 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. -- Best Regards Guo Ren [-- Attachment #1.2: Type: text/html, Size: 3350 bytes --] [-- Attachment #2: Type: text/plain, Size: 161 bytes --] _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode 2025-11-27 1:39 ` Guo Ren 2025-12-03 6:08 ` Anup Patel @ 2025-12-03 6:08 ` Anup Patel 0 siblings, 0 replies; 22+ messages in thread From: Anup Patel @ 2025-12-03 6:08 UTC (permalink / raw) To: Guo Ren Cc: Radim Krčmář, fangyu.yu, ajones, alex, aou, atish.patra, kvm-riscv, kvm, linux-kernel, linux-riscv, palmer, pjw, linux-riscv 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 -- kvm-riscv mailing list kvm-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kvm-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode @ 2025-12-03 6:08 ` Anup Patel 0 siblings, 0 replies; 22+ messages in thread From: Anup Patel @ 2025-12-03 6:08 UTC (permalink / raw) To: Guo Ren Cc: Radim Krčmář, fangyu.yu, ajones, alex, aou, atish.patra, kvm-riscv, kvm, linux-kernel, linux-riscv, palmer, pjw, linux-riscv 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode @ 2025-12-03 6:08 ` Anup Patel 0 siblings, 0 replies; 22+ messages in thread From: Anup Patel @ 2025-12-03 6:08 UTC (permalink / raw) To: Guo Ren Cc: Radim Krčmář, fangyu.yu, ajones, alex, aou, atish.patra, kvm-riscv, kvm, linux-kernel, linux-riscv, palmer, pjw, linux-riscv 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode 2025-11-25 18:15 ` Radim Krčmář (?) @ 2025-11-29 9:25 ` fangyu.yu -1 siblings, 0 replies; 22+ messages in thread From: fangyu.yu @ 2025-11-29 9:25 UTC (permalink / raw) To: rkrcmar Cc: ajones, alex, anup, aou, atish.patra, fangyu.yu, guoren, kvm-riscv, kvm, linux-kernel, linux-riscv-bounces, linux-riscv, palmer, pjw >>>> 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 -- kvm-riscv mailing list kvm-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kvm-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode @ 2025-11-29 9:25 ` fangyu.yu 0 siblings, 0 replies; 22+ messages in thread From: fangyu.yu @ 2025-11-29 9:25 UTC (permalink / raw) To: rkrcmar Cc: ajones, alex, anup, aou, atish.patra, fangyu.yu, guoren, kvm-riscv, kvm, linux-kernel, linux-riscv-bounces, linux-riscv, palmer, pjw >>>> 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode @ 2025-11-29 9:25 ` fangyu.yu 0 siblings, 0 replies; 22+ messages in thread From: fangyu.yu @ 2025-11-29 9:25 UTC (permalink / raw) To: rkrcmar Cc: ajones, alex, anup, aou, atish.patra, fangyu.yu, guoren, kvm-riscv, kvm, linux-kernel, linux-riscv-bounces, linux-riscv, palmer, pjw >>>> 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2025-12-03 6:09 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-11-22 7:50 [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode fangyu.yu 2025-11-22 7:50 ` fangyu.yu 2025-11-22 7:50 ` fangyu.yu 2025-11-23 2:33 ` Guo Ren 2025-11-23 2:33 ` Guo Ren 2025-11-23 2:33 ` Guo Ren 2025-11-24 15:27 ` Andrew Jones 2025-11-24 15:27 ` Andrew Jones 2025-11-24 15:27 ` Andrew Jones 2025-11-25 14:18 ` fangyu.yu 2025-11-25 14:18 ` fangyu.yu 2025-11-25 14:18 ` fangyu.yu 2025-11-25 18:15 ` Radim Krčmář 2025-11-25 18:15 ` Radim Krčmář 2025-11-25 18:15 ` Radim Krčmář 2025-11-27 1:39 ` Guo Ren 2025-12-03 6:08 ` Anup Patel 2025-12-03 6:08 ` Anup Patel 2025-12-03 6:08 ` Anup Patel 2025-11-29 9:25 ` fangyu.yu 2025-11-29 9:25 ` fangyu.yu 2025-11-29 9:25 ` fangyu.yu
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.