Re: [PATCH] riscv: dts: spacemit: k3: fix IMSIC guest parameters

On Sun, Aug 16, 2026 at 5:01 PM Junhui Liu <[email protected]> wrote:
>
> Hi Guo,
>
> On Sun Aug 16, 2026 at 3:41 PM CST, Guo Ren wrote:
> > From: "GUO Ren (XuanTie)" <[email protected]>
> >
> > 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: [email protected]
> > Cc: Guodong Xu <[email protected]>
> > Cc: Yixun Lan <[email protected]>
> > Signed-off-by: GUO Ren (XuanTie) <[email protected]>
> > ---
> >  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@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?

>
> >                       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@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/[email protected]/
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