linux-kernel - Re: Why two irq chips for MSI

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:   Wed, 21 Mar 2018 17:25:25 +0000
From:   Marc Zyngier <marc.zyngier@....com>
To:     valmiki <valmikibow@...il.com>,
        linux-pci <linux-pci@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc:     Bjorn Helgaas <helgaas@...nel.org>
Subject: Re: Why two irq chips for MSI

On 21/03/18 17:12, valmiki wrote:
> Hi,
> 
> In most of the RP drivers, why two irq chips are being used for MSI ?
> 
> One at irq_domain_set_info (which uses irq_compose_msi_msg and 
> irq_set_affinity methods) and another being registered with struct 
> msi_domain_info (which uses irq_mask/irq_unmask methods).
> 
> When will each chip be used w.r.t to virq ?

A simple way to think of it is that you have two pieces of HW involved:
an end-point that generates an interrupt, and a controller that receives it.

Transpose this to the kernel view of things: one chip implements the PCI
MSI, with the PCI semantics attached to it (how to program the
payload/doorbell into the end-point, for example). The other implements
the MSI controller part of it, talking to the HW that deals with the
interrupt.

Does it makes sense? Admittedly, this is not always that simple, but
that the general approach.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...