1. 03 10月, 2020 3 次提交
  2. 30 9月, 2020 1 次提交
    • N
      ACPI / NUMA: Add stub function for pxm_to_node() · 4849bc77
      Nathan Chancellor 提交于
      After commit 01feba59 ("ACPI: Do not create new NUMA domains from
      ACPI static tables that are not SRAT"):
      
      $ scripts/config --file arch/x86/configs/x86_64_defconfig -d NUMA -e ACPI_NFIT
      
      $ make -skj"$(nproc)" distclean defconfig drivers/acpi/nfit/
      drivers/acpi/nfit/core.c: In function ‘acpi_nfit_register_region’:
      drivers/acpi/nfit/core.c:3010:27: error: implicit declaration of
      function ‘pxm_to_node’; did you mean ‘xa_to_node’?
      [-Werror=implicit-function-declaration]
       3010 |   ndr_desc->target_node = pxm_to_node(spa->proximity_domain);
            |                           ^~~~~~~~~~~
            |                           xa_to_node
      cc1: some warnings being treated as errors
      ...
      
      Add a stub function like acpi_map_pxm_to_node() had so that the build
      continues to work.
      
      Fixes: 01feba59 ("ACPI: Do not create new NUMA domains from ACPI static tables that are not SRAT")
      Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
      Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
      Acked-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4849bc77
  3. 24 9月, 2020 6 次提交
    • J
      irq-chip/gic-v3-its: Fix crash if ITS is in a proximity domain without processor or memory · 95ac5bf4
      Jonathan Cameron 提交于
      Note this crash is present before any of the patches in this series, but
      as explained below it is highly unlikely anyone is shipping a firmware that
      causes it. Tests were done using an overriden SRAT.
      
      On ARM64, the gic-v3 driver directly parses SRAT to locate GIC Interrupt
      Translation Service (ITS) Affinity Structures. This is done much later
      in the boot than the parses of SRAT which identify proximity domains.
      
      As a result, an ITS placed in a proximity domain that is not defined by
      another SRAT structure will result in a NUMA node that is not completely
      configured and a crash.
      
      ITS [mem 0x202100000-0x20211ffff]
      ITS@0x0000000202100000: Using ITS number 0
      Unable to handle kernel paging request at virtual address 0000000000001a08
      ...
      
      Call trace:
        __alloc_pages_nodemask+0xe8/0x338
        alloc_pages_node.constprop.0+0x34/0x40
        its_probe_one+0x2f8/0xb18
        gic_acpi_parse_madt_its+0x108/0x150
        acpi_table_parse_entries_array+0x17c/0x264
        acpi_table_parse_entries+0x48/0x6c
        acpi_table_parse_madt+0x30/0x3c
        its_init+0x1c4/0x644
        gic_init_bases+0x4b8/0x4ec
        gic_acpi_init+0x134/0x264
        acpi_match_madt+0x4c/0x84
        acpi_table_parse_entries_array+0x17c/0x264
        acpi_table_parse_entries+0x48/0x6c
        acpi_table_parse_madt+0x30/0x3c
        __acpi_probe_device_table+0x8c/0xe8
        irqchip_init+0x3c/0x48
        init_IRQ+0xcc/0x100
        start_kernel+0x33c/0x548
      
      ACPI 6.3 allows any set of Affinity Structures in SRAT to define a proximity
      domain.  However, as we do not see this crash, we can conclude that no
      firmware is currently placing an ITS in a node that is separate from
      those containing memory and / or processors.
      
      We could modify the SRAT parsing behavior to identify the existence
      of Proximity Domains unique to the ITS structures, and handle them as
      a special case of a generic initiator (once support for those merges).
      
      This patch avoids the complexity that would be needed to handle this corner
      case, by not allowing the ITS entry parsing code to instantiate new NUMA
      Nodes.  If one is encountered that does not already exist, then NO_NUMA_NODE
      is assigned and a warning printed just as if the value had been greater than
      allowed NUMA Nodes.
      
      "SRAT: Invalid NUMA node -1 in ITS affinity"
      
      Whilst this does not provide the full flexibility allowed by ACPI,
      it does fix the problem.  We can revisit a more sophisticated solution if
      needed by future platforms.
      
      Change is simply to replace acpi_map_pxm_to_node with pxm_to_node reflecting
      the fact a new mapping is not created.
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      95ac5bf4
    • J
      ACPI: Remove side effect of partly creating a node in acpi_get_node() · a62d07e0
      Jonathan Cameron 提交于
      acpi_get_node() calls acpi_get_pxm() to evaluate the _PXM AML method
      for entries found in DSDT/SSDT. ACPI 6.3 sec 6.2.14 states
      "_PXM evaluates to an integer that identifies a device as belonging to
       a Proximity Domain defined in the System Resource Affinity Table (SRAT)."
      Hence a _PXM method should not result in creation of a new NUMA node.
      
      Before this patch, _PXM could result in partial instantiation of
      NUMA node, missing elements such as zone lists.  A call to
      devm_kzalloc(), for example, results in a NULL pointer dereference.
      
      This patch therefore replaces the acpi_map_pxm_to_node() with a call
      to pxm_to_node().
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
      Reviewed-by: NBarry Song <song.bao.hua@hisilicon.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a62d07e0
    • J
      ACPI: Rename acpi_map_pxm_to_online_node() to pxm_to_online_node() · 4eb3723f
      Jonathan Cameron 提交于
      As this function is no longer allowed to create new mappings
      let us rename it to reflect this.
      
      Note all nodes should already exist before any of the users
      of this function are called.
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4eb3723f
    • J
      ACPI: Remove side effect of partly creating a node in acpi_map_pxm_to_online_node() · fe205d98
      Jonathan Cameron 提交于
      While this function will only return an online node, it can have the side
      effect of partially creating a new node.  The existing comments suggest this
      is intentional, but the usecases of this function are related to NFIT and
      HMAT parsing, neither of which should be able to define new nodes.
      
      One route by which the existing behaviour would cause a crash is to have a
      _PXM entry in ACPI DSDT attempt to place a device within this partly
      created proximity domain. A subsequent call to devm_kzalloc() or similar
      would result in an attempt to allocate memory on a node for which zone
      lists have not been set up and a NULL pointer dereference.
      
      Prevent such cases by switching to pxm_to_node() within
      acpi_map_pxm_to_online_node() which cannot cause a new node to be
      partly created. If one would previously have been created we now
      return NO_NUMA_NODE.  Documentation updated to reflect this change.
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      fe205d98
    • J
      ACPI: Do not create new NUMA domains from ACPI static tables that are not SRAT · 01feba59
      Jonathan Cameron 提交于
      Several ACPI static tables contain references to proximity domains.
      
      ACPI 6.3 has clarified that only entries in SRAT may define a new
      domain (sec 5.2.16).
      
      Those tables described in the ACPI spec have additional clarifying text.
      
      NFIT: Table 5-132,
      
      "Integer that represents the proximity domain to which the memory
       belongs. This number must match with corresponding entry in the
       SRAT table."
      
      HMAT: Table 5-145,
      
      "... This number must match with the corresponding entry in the SRAT
       table's processor affinity structure ... if the initiator is a processor,
       or the Generic Initiator Affinity Structure if the initiator is a generic
       initiator".
      
      IORT and DMAR are defined by external specifications.
      
      Intel Virtualization Technology for Directed I/O Rev 3.1 does not make any
      explicit statements, but the general SRAT statement above will still apply.
      https://software.intel.com/sites/default/files/managed/c5/15/vt-directed-io-spec.pdf
      
      IO Remapping Table, Platform Design Document rev D, also makes not explicit
      statement, but refers to ACPI SRAT table for more information and again the
      generic SRAT statement above applies.
      https://developer.arm.com/documentation/den0049/d/
      
      In conclusion, any proximity domain specified in these tables, should be a
      reference to a proximity domain also found in SRAT, and they should not be
      able to instantiate a new domain.  Hence we switch to pxm_to_node() which
      will only return existing nodes.
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Reviewed-by: NBarry Song <song.bao.hua@hisilicon.com>
      Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      01feba59
    • J
      ACPI: Add out of bounds and numa_off protections to pxm_to_node() · 8a3decac
      Jonathan Cameron 提交于
      The function should check the validity of the pxm value before using
      it to index the pxm_to_node_map[] array.
      
      Whilst hardening this code may be good in general, the main intent
      here is to enable following patches that use this function to replace
      acpi_map_pxm_to_node() for non SRAT usecases which should return
      NO_NUMA_NODE for PXM entries not matching with those in SRAT.
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Reviewed-by: NBarry Song <song.bao.hua@hisilicon.com>
      Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8a3decac
  4. 21 9月, 2020 14 次提交
  5. 20 9月, 2020 16 次提交