[PATCH] riscv: dts: spacemit: k3: fix IMSIC guest parameters
Guo Ren
guoren at kernel.org
Sun Aug 16 18:37:33 PDT 2026
On Mon, Aug 17, 2026 at 8:51 AM Guo Ren <guoren at kernel.org> wrote:
>
> On Sun, Aug 16, 2026 at 5:01 PM Junhui Liu <junhui.liu at pigmoral.tech> wrote:
> >
> > Hi Guo,
> >
> > On Sun Aug 16, 2026 at 3:41 PM CST, Guo Ren wrote:
> > > From: "GUO Ren (XuanTie)" <guoren at kernel.org>
> > >
> > > The initial K3 device tree used generic/placeholder values for the
> > > IMSIC guest configuration:
> > >
> > > riscv,guest-index-bits = <6>;
> > > riscv,num-guest-ids = <511>;
> > >
> > > According to the SpacemiT K3 User Manual [1], these values are
> > > incorrect for the X100 cores:
> > >
> > > - Hypervisor Extension: RVH 1.0, GEILEN = 8
> > > - Advanced Interrupt Architecture (AIA):
> > > - M-mode MSI: 512
> > > - S-mode MSI: 512
> > > - VS-mode MSI: 64
> > >
> > > Therefore:
> > >
> > > - S-mode IMSIC (simsic) only needs guest-index-bits = 3 (to cover
> > > GEILEN = 8) and num-guest-ids = 63.
> > > - M-mode IMSIC (mimsic) does not implement guest interrupt files at
> > > all, so the guest-related properties must be omitted.
> > >
> > > Although the KVM AIA driver will re-detect the actual number of guest
> > > interrupt files via hgeie and correct guest-index-bits at runtime, the
> > > device tree should still describe the correct hardware parameters.
> > >
> > > Update the device tree to match the silicon.
> > >
> > > [1] https://www.spacemit.com/community/document/info?lang=en&nodepath=hardware/key_stone/k3/k3_docs/k3_usermanual/08_cpu.md
> > >
> > > Fixes: 56f37e391a62 ("riscv: dts: spacemit: add initial support for K3 SoC")
> > > Cc: stable at vger.kernel.org
> > > Cc: Guodong Xu <docular.xu at gmail.com>
> > > Cc: Yixun Lan <dlan at kernel.org>
> > > Signed-off-by: GUO Ren (XuanTie) <guoren at kernel.org>
> > > ---
> > > arch/riscv/boot/dts/spacemit/k3.dtsi | 6 ++----
> > > 1 file changed, 2 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
> > > index 19fc9b49668e..4120eb0c4083 100644
> > > --- a/arch/riscv/boot/dts/spacemit/k3.dtsi
> > > +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
> > > @@ -1127,9 +1127,9 @@ simsic: interrupt-controller at e0400000 {
> > > <&cpu4_intc 9>, <&cpu5_intc 9>,
> > > <&cpu6_intc 9>, <&cpu7_intc 9>;
> > > msi-controller;
> > > - riscv,guest-index-bits = <6>;
> > > + riscv,guest-index-bits = <3>;
> >
> > According to the IMSIC DT binding, riscv,guest-index-bits describes
> > the number of guest-index bits in the MSI target address, not the
> > number of guest interrupt files actually implemented by a hart.
> >
> > On K3, the per-hart IMSIC stride is 0x40000 bytes (0x200000 / 8).
> > Therefore, riscv,guest-index-bits should remain 6, which satisfies the
> > per-hart stride formula specified by the AIA specification:
> >
> > 2^(guest-index-bits + 12) = 2^(6 + 12) = 0x40000 bytes
> >
> > KVM already handles the difference between the address space and the
> > actual number of guest interrupt files. It reads HGEIE to find the
> > actual number of guest interrupt files and uses the smaller value:
> >
> > /*
> > * Number of usable per-HART HGEI lines should be minimum of
> > * per-HART IMSIC guest files and number of bits in HGEIE.
> > */
> > if (lc)
> > hgctrl->nr_hgei =
> > min((ulong)hgctrl->nr_hgei, lc->nr_guest_files);
> >
> > I also tested this on K3. HGEIE returned 0xfe after writing all ones,
> > so the driver gets fls_long(0xfe) - 1 = 7 usable guest interrupt file
>
> I don't think the reserved per-hart address stride alone is sufficient
> reason to set riscv,guest-index-bits to 6.
>
> As mentioned in the commit log:
> "Although the KVM AIA driver will re-detect the actual number of guest
> interrupt files via hgeie and correct guest-index-bits at runtime, the
> device tree should still describe the correct hardware parameters."
>
> Although K3 reserves a 0x40000-byte IMSIC address window per hart, only
> the first 0x8000 bytes, corresponding to guest indexes 0 through 7, are
> actually implemented. The remaining range from 0x8000 to 0x3ffff does
> not correspond to any implemented interrupt file.
>
> If we describe guest-index-bits = <6>, that raises a few questions:
> - What hardware resource is represented by guest indexes 8 through 63?
> - What behavior does the K3 hardware guarantee for accesses to the
> unused 0x8000-0x3ffff range?
> - Shall we let the kernel map that unused range and consume
> additional page-table entries for it?
After re-reading imsic_parse_fwnode(), you're right. I misunderstood
the semantics here. riscv,guest-index-bits is used to describe the
guest-index field in the IMSIC address layout and therefore determines
the per-hart address stride; it does not directly represent the number
of guest interrupt files actually implemented.
Thanks to you & sashiko-bot for pointing this out.
>
> >
> > > riscv,hart-index-bits = <4>;
> > > - riscv,num-guest-ids = <511>;
> > > + riscv,num-guest-ids = <63>;
> >
> > This change looks good to me.
> Thx for the review.
>
> >
> > > riscv,num-ids = <511>;
> > > };
> > >
> > > @@ -1168,9 +1168,7 @@ mimsic: interrupt-controller at f1000000 {
> > > <&cpu4_intc 11>, <&cpu5_intc 11>,
> > > <&cpu6_intc 11>, <&cpu7_intc 11>;
> > > msi-controller;
> > > - riscv,guest-index-bits = <6>;
> > > riscv,hart-index-bits = <4>;
> > > - riscv,num-guest-ids = <511>;
> > > riscv,num-ids = <511>;
> > > status = "reserved";
> > > };
> >
> > For the mimsic part, I already sent a related fix earlier:
> > https://lore.kernel.org/linux-riscv/20260729-k3-mimsic-fix-v1-1-368c0aec04b9@pigmoral.tech/
> Okay, I would remove the mimsic part.
>
> >
> > If you would like, you can pick that patch and combine the two changes
> > into a v2, as Yixun suggested.
>
> --
> Best Regards
> Guo Ren
--
Best Regards
Guo Ren
More information about the linux-riscv
mailing list