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: <058aed14-3644-5fc4-8eda-ec645df91836@loongson.cn>
Date:   Mon, 18 Jul 2022 09:07:21 +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/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.

> 	M.
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ