linux-kernel - [PATCH 0/9] Remove irq_remapping_get_irq

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: <20201013081139.1558200-1-dwmw2@infradead.org>
Date:   Tue, 13 Oct 2020 09:11:30 +0100
From:   David Woodhouse <dwmw2@...radead.org>
To:     x86@...nel.org
Cc:     kvm <kvm@...r.kernel.org>, iommu@...ts.linux-foundation.org,
        joro@...tes.org, Thomas Gleixner <tglx@...utronix.de>,
        Paolo Bonzini <pbonzini@...hat.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-hyperv@...r.kernel.org, maz@...terjones.org
Subject: [PATCH 0/9] Remove irq_remapping_get_irq_domain()

I didn't much like the I/OAPIC and HPET drivers having magical knowledge
that they had to substitute x86_vector_domain if their call to
irq_remapping_get_irq_domain() returned NULL.

When Thomas tried to make it handle error returns from …get_irq_domain() 
distinctly from the NULL case too, it made me even sadder. So I killed 
it with fire.

Now they just use irq_find_matching_fwspec() to find an appropriate
irqdomain. Each remapping irqdomain just needs to say 'yep, that's me'
for the HPETs or I/OAPICs which are within their scope, while the
x86_vector_domain accepts them all but only if interrupt remapping
is *disabled*. No more special knowledge in the caller.

If IR is enabled and there's a child device which escapes the scope of
all remapping units, it gets NULL for its parent irqdomain and will
fail to initialise, which is the correct thing to do in that "should
never happen" case. For HPET that'll mean that it just doesn't support
MSI, while I/OAPIC will refuse to initialise and trigger a BUG_ON
because Linux quite likes it when *all* the I/OAPICs it knows about get
initialised successfully.

This is on top of the previous 'ext_dest_id' series at
https://patchwork.kernel.org/project/kvm/list/?series=362037

https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/ext_dest_id

David Woodhouse (9):
      genirq/irqdomain: Implement get_name() method on irqchip fwnodes
      x86/apic: Add select() method on vector irqdomain
      iommu/amd: Implement select() method on remapping irqdomain
      iommu/vt-d: Implement select() method on remapping irqdomain
      iommu/hyper-v: Implement select() method on remapping irqdomain
      x86/hpet: Use irq_find_matching_fwspec() to find remapping irqdomain
      x86/ioapic: Use irq_find_matching_fwspec() to find remapping irqdomain
      x86: Kill all traces of irq_remapping_get_irq_domain()
      iommu/vt-d: Simplify intel_irq_remapping_select()

 arch/x86/include/asm/hw_irq.h        |  2 --
 arch/x86/include/asm/irq_remapping.h |  9 ---------
 arch/x86/include/asm/irqdomain.h     |  3 +++
 arch/x86/kernel/apic/io_apic.c       | 24 ++++++++++++------------
 arch/x86/kernel/apic/vector.c        | 43 +++++++++++++++++++++++++++++++++++++++++++
 arch/x86/kernel/hpet.c               | 23 +++++++++++++----------
 drivers/iommu/amd/iommu.c            | 53 +++++++++++++++++++----------------------------------
 drivers/iommu/hyperv-iommu.c         | 18 +++++++++---------
 drivers/iommu/intel/irq_remapping.c  | 43 +++++++++++++++++--------------------------
 drivers/iommu/irq_remapping.c        | 14 --------------
 drivers/iommu/irq_remapping.h        |  3 ---
 kernel/irq/irqdomain.c               | 11 ++++++++++-
 12 files changed, 126 insertions(+), 120 deletions(-)