linux-kernel - Re: [PATCH 0/2] riscv,aplic: support for hart indexes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAhSdy0cBkogjR1DbcS9-TLRbKiDqVTydrYQCihnEHDRu69CoQ@mail.gmail.com>
Date: Thu, 2 Jan 2025 18:18:17 +0530
From: Anup Patel <anup@...infault.org>
To: Vladimir Kondratiev <vladimir.kondratiev@...ileye.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Paul Walmsley <paul.walmsley@...ive.com>, 
	Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] riscv,aplic: support for hart indexes

On Thu, Jan 2, 2025 at 3:11 PM Vladimir Kondratiev
<vladimir.kondratiev@...ileye.com> wrote:
>
> Risc-v APLIC uses "hart index" to access data per destination hart.
> Current implementation assumes hart indexes are consecutive integers
> starting from 0, while Risc-V documentation says it may be
> arbitrary numbers, with a clue that it may be related to the hart IDs.
>
> In all boards I see in today's kernel, hart IDs are consecutive
> integers, thus using dart IDs is the same as indexes.
>
> However, for the MIPS P8700, hart IDs are different from indexes,
> on this SoC they encode thread number, core and cluster in bits
> [0..3], [4..15], [16..19] resulting Soc consisting of 3 clusters *
> 4 cores * 2 threads with hart IDs:
> 0x0, 0x1, 0x10, 0x11, 0x20, 0x21, 0x30, 0x31, 0x10000 etc.
>
> Change default hart index to be hart ID related to the start of domain,
> and add optional property to configure arbitrary indexes.

We don't need any APLIC DT binding change for supporting random
HART ID assignments. Please see below for a detailed explanation.

>
> Use of "device_property" API allows to cover both ACPI and OF in single
> code
>
> 1-st commit adds dt-bindings, 2-nd - code
>
> Vladimir Kondratiev (2):
>   dt-bindings: interrupt-controller: add risc-v,aplic hart indexes
>   irqchip/riscv-aplic: add support for hart indexes

The RISC-V APLIC driver does not assume any correlation between
APLIC "HART Index" and the actual HART ID of various HARTs.

Each APLIC domain has its own 14bit "HART Index" space and the
APLIC driver determines "HART Index" based on the APLIC mode
(Direct/MSI mode).

The APLIC domain in direct mode requires "HART Index" to be
between 0 to N - 1 where N is the number of HARTs targeted by
the APLIC domain because the APLIC IDC structures are placed
consecutively in the MMIO space and located based on "HART index".
(Refer, first paragraph of the section "4.8 Interrupt delivery directly
by the APLIC" of the ratified RISC-V AIA v1.0 specification)

On the other hand, there is no constraint on the "HART Index" space
for the APLIC domain in MSI mode because the "HART Index" bits
are part of the MSI target address generated by APLIC.
(Refer, section "4.9.1 Addresses and data for outgoing MSIs" of
the ratified RISC-V AIA v1.0 specification).

The RISC-V APLIC direct mode driver uses the "interrupts-extended"
DT property to determine how an APLIC domain connects to a
set of HARTs. Here's how this DT property is used:
1) The number of entries in the "interrupts-extended" DT property
tells the number of APLIC IDC structures where the first entry is for
"HART Index = 0", the second entry is for "HART Index = 1" and so on.
2) The first value (aka phandle) of each entry in the "interrupts-extended"
DT property points to the target HART INTC.
3) The second value of each entry in the "interrupts-extended" DT
property determines the target privilege level on the HART. For
example, 11 means "M-mode external interrupt" and 9 means
"S-mode external interrupt"

The RISC-V APLIC MSI mode driver extracts the "HART Index"
the target MSI address and the RISC-V IMSIC driver selects
the target HART for handling a particular APLIC MSI-mode
interrupt.

Clearly, the APLIC DT binding is flexible and does not depend
upon the HART IDs assigned to the HARTs.

The "Example1" of the riscv,aplic.yaml already shows three
different APLIC domains targeting different sets of HARTs and
privilege levels. In fact, the upstream QEMU virt machine already
supports creating up to 8 APLIC domains in direct mode where
each targets a different set of HARTs and privilege levels.

Regards,
Anup