Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 18 3月, 2021 3 次提交
  3. 12 2月, 2021 1 次提交
  5. 28 1月, 2021 2 次提交
  7. 27 1月, 2021 2 次提交
  9. 06 1月, 2021 1 次提交
  11. 11 12月, 2020 1 次提交
  13. 23 11月, 2020 1 次提交
  15. 19 11月, 2020 1 次提交
    • D
      iommu/amd: Fix IOMMU interrupt generation in X2APIC mode · d1adcfbb
      由 David Woodhouse 提交于 
      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: NDavid Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NSuravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Link: https://lore.kernel.org/r/05e3a5ba317f5ff48d2f8356f19e617f8b9d23a4.camel@infradead.org
      d1adcfbb
  17. 12 11月, 2020 2 次提交
  19. 29 10月, 2020 1 次提交
  21. 01 10月, 2020 1 次提交
  23. 24 9月, 2020 2 次提交
  25. 04 9月, 2020 2 次提交
  27. 24 8月, 2020 1 次提交
  29. 22 7月, 2020 1 次提交
  31. 30 6月, 2020 1 次提交
    • P
      iommu/amd: Print extended features in one line to fix divergent log levels · 9a295ff0
      由 Paul Menzel 提交于 
      Currently, Linux logs the two messages below.

    [    0.979142] pci 0000:00:00.2: AMD-Vi: Extended features (0xf77ef22294ada):
    [    0.979546]  PPR NX GT IA GA PC GA_vAPIC

The log level of these lines differs though. The first one has level
*info*, while the second has level *warn*, which is confusing.

    $ dmesg -T --level=info | grep "Extended features"
    [Tue Jun 16 21:46:58 2020] pci 0000:00:00.2: AMD-Vi: Extended features (0xf77ef22294ada):
    $ dmesg -T --level=warn | grep "PPR"
    [Tue Jun 16 21:46:58 2020]  PPR NX GT IA GA PC GA_vAPIC

The problem is, that commit 3928aa3f ("iommu/amd: Detect and enable
guest vAPIC support") introduced a newline, causing `pr_cont()`, used to
print the features, to default back to the default log level.

    /**
     * pr_cont - Continues a previous log message in the same line.
     * @fmt: format string
     * @...: arguments for the format string
     *
     * This macro expands to a printk with KERN_CONT loglevel. It should only be
     * used when continuing a log message with no newline ('\n') enclosed. Otherwise
     * it defaults back to KERN_DEFAULT loglevel.
     */
    #define pr_cont(fmt, ...) \
            printk(KERN_CONT fmt, ##__VA_ARGS__)

So, remove the line break, so only one line is logged.

Fixes: 3928aa3f ("iommu/amd: Detect and enable guest vAPIC support")
Signed-off-by: NPaul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: NSuravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: iommu@lists.linux-foundation.org
Link: https://lore.kernel.org/r/20200616220420.19466-1-pmenzel@molgen.mpg.deSigned-off-by: NJoerg Roedel <jroedel@suse.de>
      9a295ff0
  33. 10 6月, 2020 1 次提交
  35. 29 5月, 2020 1 次提交
  37. 13 5月, 2020 1 次提交
    • A
      iommu/amd: Fix over-read of ACPI UID from IVRS table · e461b8c9
      由 Alexander Monakov 提交于 
      IVRS parsing code always tries to read 255 bytes from memory when
retrieving ACPI device path, and makes an assumption that firmware
provides a zero-terminated string. Both of those are bugs: the entry
is likely to be shorter than 255 bytes, and zero-termination is not
guaranteed.

With Acer SF314-42 firmware these issues manifest visibly in dmesg:

AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR0\xf0\xa5, rdevid:160
AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR1\xf0\xa5, rdevid:160
AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR2\xf0\xa5, rdevid:160
AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR3>\x83e\x8d\x9a\xd1...

The first three lines show how the code over-reads adjacent table
entries into the UID, and in the last line it even reads garbage data
beyond the end of the IVRS table itself.

Since each entry has the length of the UID (uidl member of ivhd_entry
struct), use that for memcpy, and manually add a zero terminator.

Avoid zero-filling hid and uid arrays up front, and instead ensure
the uid array is always zero-terminated. No change needed for the hid
array, as it was already properly zero-terminated.

Fixes: 2a0cb4e2 ("iommu/amd: Add new map for storing IVHD dev entry type HID")
Signed-off-by: NAlexander Monakov <amonakov@ispras.ru>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: iommu@lists.linux-foundation.org
Link: https://lore.kernel.org/r/20200511102352.1831-1-amonakov@ispras.ruSigned-off-by: NJoerg Roedel <jroedel@suse.de>
      e461b8c9
  39. 01 5月, 2020 1 次提交
  41. 19 2月, 2020 1 次提交
  43. 24 1月, 2020 1 次提交
  45. 17 1月, 2020 1 次提交
  47. 07 1月, 2020 2 次提交
  49. 06 1月, 2020 1 次提交
  51. 23 12月, 2019 4 次提交
  53. 23 8月, 2019 1 次提交
  55. 23 7月, 2019 1 次提交
  57. 01 7月, 2019 1 次提交
    • K
      iommu/amd: Only free resources once on init error · 5c90501a
      由 Kevin Mitchell 提交于 
      When amd_iommu=off was specified on the command line, free_X_resources
functions were called immediately after early_amd_iommu_init. They were
then called again when amd_iommu_init also failed (as expected).

Instead, call them only once: at the end of state_next() whenever
there's an error. These functions should be safe to call any time and
any number of times. However, since state_next is never called again in
an error state, the cleanup will only ever be run once.

This also ensures that cleanup code is run as soon as possible after an
error is detected rather than waiting for amd_iommu_init() to be called.
Signed-off-by: NKevin Mitchell <kevmitch@arista.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      5c90501a