linux-kernel - Re: [PATCH 0/6] Implement generic IPI support mechanism

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: <5603B6CA.7050601@imgtec.com>
Date:	Thu, 24 Sep 2015 09:39:38 +0100
From:	Qais Yousef <qais.yousef@...tec.com>
To:	Jiang Liu <jiang.liu@...ux.intel.com>,
	<linux-kernel@...r.kernel.org>, <tglx@...utronix.de>
CC:	<marc.zyngier@....com>, <jason@...edaemon.net>,
	<linux-mips@...ux-mips.org>
Subject: Re: [PATCH 0/6] Implement generic IPI support mechanism

On 09/23/2015 05:54 PM, Jiang Liu wrote:
> On 2015/9/23 22:49, Qais Yousef wrote:
>> This RFC series attempts to implement a generic IPI layer for reserving and sending IPI.
>>
>> It is based on the discussion in this link
>>
>> 	https://lkml.org/lkml/2015/8/26/713
>>
>> This series deals with points #1 and #2 only. Since I'm not the irq expert, I'm hoping this
>> series will give me early feedback and drive the discussion further about any potential
>> tricky points.
>>
>> I tried to keep changes clean and small, but since this is just an RFC I might have missed
>> few things.
>>
>> Thomas I hope I didn't stray far from what you had in mind :-)
>>
>> My only testing so far is having SMP linux booting.
> Hi Qais,
> 	Thanks for doing this, but the change is a little bigger than
> my expectation. Could we achieve this by:
> 1) extend irq_chip to support send_ipi operation
> 2) reuse existing irqdomain allocation interfaces to allocate IPI IRQ
> 3) arch code to create an IPI domain for IPI allocations
> 4) IRQ core provides some helpers to help arch code to implement IPI
>     irqdomain
> 	I think that may make the change smaller and more clear.
> Thanks!
> Gerry
>
>


Can you be more specific about 2 please? I tried to reuse the hierarchy 
irqdomain alloc function. One major difference when allocating IPI than 
a normal irq is that it's dynamic. The caller doesn't know what hwirq 
number it needs. It actually shouldn't.

The idea is for the user to just say 'I want an IPI to a CPUAFFINITY' 
from DT and get a virq in return to send an IPI to the target CPU(s). 
Also I think we need to accommodate the possibility of having more than 
1 IPI controller.

Can you provide more pointers please?

Thanks,
Qais
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/