1. 18 Nov, 2020 1 commit
    • David Woodhouse's avatar
      iommu/amd: Fix IOMMU interrupt generation in X2APIC mode · d1adcfbb
      David Woodhouse authored
      The AMD IOMMU has two modes for generating its own interrupts.
      
      The first is very much based on PCI MSI, and can be configured by Linux
      precisely that way. But like legacy unmapped PCI MSI it's limited to
      8 bits of APIC ID.
      
      The second method does not use PCI MSI at all in hardawre, and instead
      configures the INTCAPXT registers in the IOMMU directly with the APIC ID
      and vector.
      
      In the latter case, the IOMMU driver would still use pci_enable_msi(),
      read back (through MMIO) the MSI message that Linux wrote to the PCI MSI
      table, then swizzle those bits into the appropriate register.
      
      Historically, this worked because__irq_compose_msi_msg() would silently
      generate an invalid MSI message with the high bits of the APIC ID in the
      high bits of the MSI address. That hack was intended only for the Intel
      IOMMU, and I recently enforced that, introducing a warning in
      __irq_msi_compose_msg() if it was invoked with an APIC ID above 255.
      
      Fix the AMD IOMMU not to depend on that hack any more, by having its own
      irqdomain and directly putting the bits from the irq_cfg into the right
      place in its ->activate() method.
      
      Fixes: 47bea873 "x86/msi: Only use high bits of MSI address for DMAR unit")
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarSuravee Suthikulpanit <suravee.suthikulpanit@amd.com>
      Link: https://lore.kernel.org/r/05e3a5ba317f5ff48d2f8356f19e617f8b9d23a4.camel@infradead.org
      d1adcfbb
  2. 11 Nov, 2020 2 commits
  3. 10 Nov, 2020 1 commit
  4. 04 Nov, 2020 2 commits
    • David Woodhouse's avatar
      x86/ioapic: Use I/O-APIC ID for finding irqdomain, not index · f36a74b9
      David Woodhouse authored
      In commit b643128b ("x86/ioapic: Use irq_find_matching_fwspec() to
      find remapping irqdomain") the I/O-APIC code was changed to find its
      parent irqdomain using irq_find_matching_fwspec(), but the key used
      for the lookup was wrong. It shouldn't use 'ioapic' which is the index
      into its own ioapics[] array. It should use the actual arbitration
      ID of the I/O-APIC in question, which is mpc_ioapic_id(ioapic).
      
      Fixes: b643128b ("x86/ioapic: Use irq_find_matching_fwspec() to find remapping irqdomain")
      Reported-by: default avatarlkp <oliver.sang@intel.com>
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Link: https://lore.kernel.org/r/57adf2c305cd0c5e9d860b2f3007a7e676fd0f9f.camel@infradead.org
      f36a74b9
    • Dexuan Cui's avatar
      x86/hyperv: Enable 15-bit APIC ID if the hypervisor supports it · d981059e
      Dexuan Cui authored
      When a Linux VM runs on Hyper-V, if the VM has CPUs with >255 APIC IDs,
      the CPUs can't be the destination of IOAPIC interrupts, because the
      IOAPIC RTE's Dest Field has only 8 bits. Currently the hackery driver
      drivers/iommu/hyperv-iommu.c is used to ensure IOAPIC interrupts are
      only routed to CPUs that don't have >255 APIC IDs. However, there is
      an issue with kdump, because the kdump kernel can run on any CPU, and
      hence IOAPIC interrupts can't work if the kdump kernel run on a CPU
      with a >255 APIC ID.
      
      The kdump issue can be fixed by the Extended Dest ID, which is introduced
      recently by David Woodhouse (for IOAPIC, see the field virt_destid_8_14 in
      struct IO_APIC_route_entry). Of course, the Extended Dest ID needs the
      support of the underlying hypervisor. The latest Hyper-V has added the
      support recently: with this commit, on such a Hyper-V host, Linux VM
      does not use hyperv-iommu.c because hyperv_prepare_irq_remapping()
      returns -ENODEV; instead, Linux kernel's generic support of Extended Dest
      ID from David is used, meaning that Linux VM is able to support up to
      32K CPUs, and IOAPIC interrupts can be routed to all the CPUs.
      
      On an old Hyper-V host that doesn't support the Extended Dest ID, nothing
      changes with this commit: Linux VM is still able to bring up the CPUs with
      > 255 APIC IDs with the help of hyperv-iommu.c, but IOAPIC interrupts still
      can not go to such CPUs, and the kdump kernel still can not work properly
      on such CPUs.
      
      [ tglx: Updated comment as suggested by David ]
      Signed-off-by: default avatarDexuan Cui <decui@microsoft.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Link: https://lore.kernel.org/r/20201103011136.59108-1-decui@microsoft.com
      d981059e
  5. 28 Oct, 2020 34 commits