linux-kernel - Re: [PATCH V15 00/15] irqchip: Add LoongArch-related irqchip drivers

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]

Date:   Mon, 18 Jul 2022 16:29:30 +0800
From:   Jianmin Lv <lvjianmin@...ngson.cn>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
        loongarch@...ts.linux.dev, Hanjun Guo <guohanjun@...wei.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        Huacai Chen <chenhuacai@...ngson.cn>
Subject: Re: [PATCH V15 00/15] irqchip: Add LoongArch-related irqchip drivers



On 2022/7/18 下午2:39, Marc Zyngier wrote:
> On Mon, 18 Jul 2022 02:07:21 +0100,
> Jianmin Lv <lvjianmin@...ngson.cn> wrote:
>>
>>
>>
>> On 2022/7/17 下午10:49, Marc Zyngier wrote:
>>> On Sun, 17 Jul 2022 12:29:05 +0100,
>>> Jianmin Lv <lvjianmin@...ngson.cn> wrote:
>>>>
>>>>
>>>>
>>>> On 2022/7/17 下午6:02, Marc Zyngier wrote:
>>>>> But the other issue is that you seem to call this function from two
>>>>> different locations. This cannot be right, as there should be only one
>>>>> probe order, and not multiple.
>>>>>
>>>>
>>>> As we described two IRQ models(Legacy and Extended) in this cover
>>>> letter, the parent domain of MSI domain can be htvec domain(Legacy) or
>>>> eiointc domain(Extended). In MADT, only one APIC(HTPIC for htvec or
>>>> EIOPIC for eiointc) is allowed to pass into kernel, and then in the
>>>> irqchip driver, only one kind APIC of them can be parsed from MADT, so
>>>> we have to support two probe order for them.
>>>
>>> Do you really have the two variants in the wild? Or is this just
>>> because this is a possibility?
>>>
>>
>> Currently, there are not CPUs(used for PC and server) based on
>> LoongArch shipped with only HTPIC, but with both HTPIC and EIOPIC, we
>> just want to provide two choices for designers(but obviously, EIOPIC
>> may be enough currently). Do you think we don't have to do like this,
>> yes? If so, maybe we don't have to support ACPI-way entry for htvec
>> currently, and do the work in future if required.
> 
> If the existing HW is only following the 'Extended' model, then I'd
> suggest you only support this for now. It has two effects:
> 
> - it simplifies the current code, making it more maintainable and
>    easier to reason about
> 
> - it sends the message to integrators that 'Extended' is the correct
>    model, and that it is what they should support
> 
> Now, we don't have much time left to get this series into -next (I
> will be closing the tree to new features this week, and only queue
> fixes).
> 
> So whatever you need to do, please do it quickly so that we can have
> at least some of this in 5.20.
> 
> Thanks,
> 
> 	M.
> 

Ok, Marc, thanks for your suggestion, got it, I'll remove 'Legacy' mode 
support and send next version as soon as possible.