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

On Mon, Aug 17, 2026 at 8:51 AM Guo Ren <[email protected]> wrote:
>
> 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?

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



-- 
Best Regards
 Guo Ren