From: fangyu.yu@linux.alibaba.com
To: ajones@ventanamicro.com
Cc: alex@ghiti.fr, anup@brainfault.org, aou@eecs.berkeley.edu,
atish.patra@linux.dev, fangyu.yu@linux.alibaba.com,
guoren@kernel.org, kvm-riscv@lists.infradead.org,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org, palmer@dabbelt.com,
pjw@kernel.org
Subject: Re: [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode
Date: Tue, 25 Nov 2025 22:18:11 +0800 [thread overview]
Message-ID: <20251125141811.39964-1-fangyu.yu@linux.alibaba.com> (raw)
In-Reply-To: <20251124-4ecf1b6b91b8f0688b762698@orel>
>> 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
next prev parent reply other threads:[~2025-11-25 14:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-22 7:50 [PATCH] RISC-V: KVM: Allow to downgrade HGATP mode via SATP mode fangyu.yu
2025-11-23 2:33 ` Guo Ren
2025-11-24 15:27 ` Andrew Jones
2025-11-25 14:18 ` fangyu.yu [this message]
2025-11-25 18:15 ` Radim Krčmář
2025-11-27 1:39 ` Guo Ren
2025-12-03 6:08 ` Anup Patel
2025-11-29 9:25 ` fangyu.yu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251125141811.39964-1-fangyu.yu@linux.alibaba.com \
--to=fangyu.yu@linux.alibaba.com \
--cc=ajones@ventanamicro.com \
--cc=alex@ghiti.fr \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=atish.patra@linux.dev \
--cc=guoren@kernel.org \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox