linux-kernel - RE: [PATCH RFC v2 02/18] irq/dev-msi: Add support for a new DEV

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: <87tuxfhf9u.fsf@nanos.tec.linutronix.de>
Date:   Thu, 06 Aug 2020 19:10:05 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Dey\, Megha" <megha.dey@...el.com>,
        Jason Gunthorpe <jgg@...lanox.com>
Cc:     Marc Zyngier <maz@...nel.org>,
        "Jiang\, Dave" <dave.jiang@...el.com>,
        "vkoul\@kernel.org" <vkoul@...nel.org>,
        "bhelgaas\@google.com" <bhelgaas@...gle.com>,
        "rafael\@kernel.org" <rafael@...nel.org>,
        "gregkh\@linuxfoundation.org" <gregkh@...uxfoundation.org>,
        "hpa\@zytor.com" <hpa@...or.com>,
        "alex.williamson\@redhat.com" <alex.williamson@...hat.com>,
        "Pan\, Jacob jun" <jacob.jun.pan@...el.com>,
        "Raj\, Ashok" <ashok.raj@...el.com>,
        "Liu\, Yi L" <yi.l.liu@...el.com>,
        "Lu\, Baolu" <baolu.lu@...el.com>,
        "Tian\, Kevin" <kevin.tian@...el.com>,
        "Kumar\, Sanjay K" <sanjay.k.kumar@...el.com>,
        "Luck\, Tony" <tony.luck@...el.com>,
        "Lin\, Jing" <jing.lin@...el.com>,
        "Williams\, Dan J" <dan.j.williams@...el.com>,
        "kwankhede\@nvidia.com" <kwankhede@...dia.com>,
        "eric.auger\@redhat.com" <eric.auger@...hat.com>,
        "parav\@mellanox.com" <parav@...lanox.com>,
        "Hansen\, Dave" <dave.hansen@...el.com>,
        "netanelg\@mellanox.com" <netanelg@...lanox.com>,
        "shahafs\@mellanox.com" <shahafs@...lanox.com>,
        "yan.y.zhao\@linux.intel.com" <yan.y.zhao@...ux.intel.com>,
        "pbonzini\@redhat.com" <pbonzini@...hat.com>,
        "Ortiz\, Samuel" <samuel.ortiz@...el.com>,
        "Hossain\, Mona" <mona.hossain@...el.com>,
        "dmaengine\@vger.kernel.org" <dmaengine@...r.kernel.org>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86\@kernel.org" <x86@...nel.org>,
        "linux-pci\@vger.kernel.org" <linux-pci@...r.kernel.org>,
        "kvm\@vger.kernel.org" <kvm@...r.kernel.org>
Subject: RE: [PATCH RFC v2 02/18] irq/dev-msi: Add support for a new DEV_MSI irq domain

Megha,

"Dey, Megha" <megha.dey@...el.com> writes:

>> -----Original Message-----
>> From: Jason Gunthorpe <jgg@...lanox.com>
<SNIP>
>> Subject: Re: [PATCH RFC v2 02/18] irq/dev-msi: Add support for a new DEV_MSI
>> irq domain

can you please fix your mail client not to copy the whole header of the
mail you are replying to into the mail body?

>> > > Well, I had suggested to pass in the parent struct device, but it
>> Oops, I was thinking of platform_msi_domain_alloc_irqs() not
>> create_device_domain()
>> 
>> ie call it in the device driver that wishes to consume the extra MSIs.
>> 
>> Is there a harm if each device driver creates a new irq_domain for its use?
>
> Well, the only harm is if we want to reuse the irq domain.

You cannot reuse the irq domain if you create a domain per driver. The
way how hierarchical domains work is:

vector --- DMAR-MSI
       |
       |-- ....
       |
       |-- IR-0 --- IO/APIC-0
       |        | 
       |        |-- IO/APIC-1
       |        |
       |        |-- PCI/MSI-0
       |        |
       |        |-- HPET/MSI-0
       |
       |-- IR-1 --- PCI/MSI-1
       |        |

The outermost domain is what the actual device driver uses. I.e. for
PCI-MSI it's the msi domain which is associated to the bus the device is
connected to. Each domain has its own interrupt chip instance and its
own data set.

Domains of the same type share the code, but neither the data nor the
interrupt chip instance.

Also there is a strict parent child relationship in terms of resources.
Let's look at PCI.

PCI/MSI-0 depends on IR-0 which depends on the vector domain. That's
reflecting both the flow of the interrupt and the steps required for
various tasks, e.g. allocation/deallocation and also interrupt chip
operations. In order to allocate a PCI/MSI interrupt in domain PCI/MSI-0
a slot in the remapping unit and a vector needs to be allocated.

If you disable interrupt remapping all the outermost domains in the
scheme above become childs of the vector domain.

So if we look at DEV/MSI as a infrastructure domain then the scheme
looks like this:

vector --- DMAR-MSI
       |
       |-- ....
       |
       |-- IR-0 --- IO/APIC-0
       |        | 
       |        |-- IO/APIC-1
       |        |
       |        |-- PCI/MSI-0
       |        |
       |        |-- HPET/MSI-0
       |        |
       |        |-- DEV/MSI-0
       |
       |-- IR-1 --- PCI/MSI-1
       |        |
       |        |-- DEV/MSI-1

But if you make it per device then you have multiple DEV/MSI domains per
IR unit.

What's the right thing to do?

If the DEV/MSI domain has it's own per IR unit resource management, then
you need one per IR unit.

If the resource management is solely per device then having a domain per
device is the right choice.

Thanks,

        tglx