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: <CAAhSdy2P3AQckUXaH1XY2+zK4Cx=WYDsUUciODcLbka3z9q2XQ@mail.gmail.com>
Date: Thu, 2 Jan 2025 20:11:11 +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-riscv@...ts.infradead.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] riscv,aplic: support for hart indexes

On Thu, Jan 2, 2025 at 7:31 PM Vladimir Kondratiev
<Vladimir.Kondratiev@...ileye.com> wrote:
>
> >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)
>
> Hi Anup,
>
> Sorry, perhaps I am reading spec the wrong way. I don't see where
> spec required this:
>
> >"HART Index" to be
> >between 0 to N - 1 where N is the number of HARTs targeted by
> >the APLIC domain
>
> I have a real hardware (MIPS P8700) where APLIC is in direct mode
> and hart indexes are same as hart IDs, masking out cluster number.
> These hart indexes as I mentioned, "0x00, 0x01, 0x10, 0x11" etc.
> For delivering IRQ, for example,  to CPU2 I need to access its IDC
> by hart index 0x10. Current code uses IDC at index 2 and hardware
> don't work this way because there's no registers at this address.
>
> If spec indeed requires hart indexes to be in range as you mentioned,
> such hardware is not spec compliant. Is it the case?

Here's the text from "4.8 Interrupt delivery directly by the APLIC" of
the AIA specification:

"When an interrupt domain is in direct delivery mode (domaincfg.DM = 0),
interrupts are delivered from the APLIC to harts by a unique signal to each
hart, usually a dedicated wire. In this case, the domain’s memory-mapped
control region contains at the end an array of interrupt delivery control (IDC)
structures, one IDC structure per potential hart index. The first IDC structure
is for the domain’s hart with index 0; the second is for the hart with
index 1; etc."

The AIA spec clearly says that for APLIC in direct mode requires
sequential "HART index" starting from 0 so that IDC structures can
be located using the APLIC "HART index".

The non-contiguous APLIC "HART index" assignment in MIPS P8700
is clearly a violation of the AIA specification.

>
> In addition, as spec says, hart index may be different than its hart ID
> and I don't see any provisioning in current code to supply this
> hart index.

Yes, this is true for both APLIC direct-mode as well because each
APLIC domain in direct-mode will have its own "HART index" space
starting from 0.

>
> What am I missing?

To me it seems MIPS P8700 is only IP and not actual silicon ??
(https://mips.com/products/hardware/p8700/)

If so then it is better to fix the IP itself. If it is real silicon then I can
think of some work-around for the non-compliance.

Regards,
Anup

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ