- 13 Nov, 2018 40 commits
-
-
Guilherme G. Piccoli authored
BugLink: https://bugs.launchpad.net/bugs/1797990 We observed a kdump failure in x86 that was narrowed down to MSI irq storm coming from a PCI network device. The bug manifests as a lack of progress in the boot process of kdump kernel, and a flood of kernel messages like: [...] [ 342.265294] do_IRQ: 0.155 No irq handler for vector [ 342.266916] do_IRQ: 0.155 No irq handler for vector [ 347.258422] do_IRQ: 14053260 callbacks suppressed [...] The root cause of the issue is that kexec process of the kdump kernel doesn't ensure PCI devices are reset or MSI capabilities are disabled, so a PCI adapter could produce a huge amount of irqs which would steal all the processing time for the CPU (specially since we usually restrict kdump kernel to use a single CPU only). This patch implements the kernel parameter "pci=clearmsi" to clear the MSI/MSI-X enable bits in the Message Control register for all PCI devices during early boot time, thus preventing potential issues in the kexec'ed kernel. PCI spec also supports/enforces this need (see PCI Local Bus spec sections 6.8.1.3 and 6.8.2.3). Suggested-by:
Dan Streetman <ddstreet@canonical.com> Suggested-by:
Gavin Shan <shan.gavin@linux.alibaba.com> Signed-off-by:
Guilherme G. Piccoli <gpiccoli@canonical.com> [mfo: backport to ubuntu-xenial: - different path for Documentation/.../kernel-parameters.txt - update context lines in pci-direct.h and early-quirks.c] Signed-off-by:
Mauricio Faria de Oliveira <mfo@canonical.com> Acked-by:
Khalid Elmously <khalid.elmously@canonical.com> Acked-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by:
-
Guilherme G. Piccoli authored
BugLink: https://bugs.launchpad.net/bugs/1797990 This patch exports (and renames) the function find_cap() to be used in the early PCI quirk code, by the next patch. This is being moved out from AGP code to generic early-PCI code since it's not AGP-specific and can be used for any PCI device. No functional changes intended. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1802341 In ena_remove() we have the following stack call: ena_remove() unregister_netdev() ena_destroy_device() netif_carrier_off() Calling netif_carrier_off() causes linkwatch to try to handle the link change event on the already unregistered netdev, which leads to a read from an unreadable memory address. This patch switches the order of the two functions, so that netif_carrier_off() is called on a regiestered netdev. To accomplish this fix we also had to: 1. Remove the set bit ENA_FLAG_TRIGGER_RESET 2. Add a sanitiy check in ena_close() both to prevent double device reset (when calling unregister_netdev() ena_close is called, but the device was already deleted in ena_destroy_device()). 3. Set the admin_queue running state to false to avoid using it after device was reset (for example when calling ena_destroy_all_io_queues() right after ena_com_dev_reset() in ena_down) Finally, driver version is also updated. Change-Id: I3cc1aafe9cb3701a6eaee44e00add0e175c93148 Signed-off-by:
Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
Tyler Hicks <tyhicks@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1797092 Implement pci_acpi_scan_root() and other arch-specific calls so ARM64 can use ACPI to setup and enumerate PCI buses. Use memory-mapped configuration space information from either the ACPI _CBA method or the MCFG table and the ECAM library and generic ECAM config accessor ops. Implement acpi_pci_bus_find_domain_nr() to retrieve the domain number from the acpi_pci_root structure. Implement pcibios_add_bus() and pcibios_remove_bus() to call acpi_pci_add_bus() and acpi_pci_remove_bus() for ACPI slot management and other configuration. Signed-off-by:
Tomasz Nowicki <tn@semihalf.com> Signed-off-by:
Jayachandran C <jchandra@broadcom.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> (backported from commit 0cb0786b) [ dannf: Kconfig offset fixup ] Signed-off-by:
dann frazier <dann.frazier@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1797092 To enable PCI legacy IRQs on platforms booting with ACPI, arch code should include ACPI-specific callbacks that parse and set-up the device IRQ number, equivalent to the DT boot path. Owing to the current ACPI core scan handlers implementation, ACPI PCI legacy IRQs bindings cannot be parsed at device add time, since that would trigger ACPI scan handlers ordering issues depending on how the ACPI tables are defined. To solve this problem and consolidate FW PCI legacy IRQs parsing in one single pcibios callback (pending final removal), this patch moves DT PCI IRQ parsing to the pcibios_alloc_irq() callback (called by PCI core code at driver probe time) and adds ACPI PCI legacy IRQs parsing to the same callback too, so that FW PCI legacy IRQs parsing is confined in one single arch callback that can be easily removed when code parsing PCI legacy IRQs is consolidated and moved to core PCI code. Suggested-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1797092 Extend pci_bus_find_domain_nr() so it can find the domain from either: - ACPI, via the new acpi_pci_bus_find_domain_nr() interface, or - DT, via of_pci_bus_find_domain_nr() Note that this is only used for CONFIG_PCI_DOMAINS_GENERIC=y, so it does not affect x86 or ia64. [bhelgaas: changelog] Signed-off-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1797092 pci_bus_find_domain_nr() retrieves the host bridge domain number in a DT-specific way. Rename it to of_pci_bus_find_domain_nr() to reflect that, so we can add a corresponding function for ACPI. [bhelgaas: changelog] Signed-off-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1797092 Instead of assigning bus->domain_nr inside pci_bus_assign_domain_nr(), return the domain and let the caller do the assignment. Rename pci_bus_assign_domain_nr() to pci_bus_find_domain_nr() to reflect this. No functional change intended. [bhelgaas: changelog] Signed-off-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1797092 On ACPI systems that support memory-mapped config space access, i.e., ECAM, the PCI Firmware Specification says the OS can learn where the ECAM space is from either: - the static MCFG table (for non-hotpluggable bridges), or - the _CBA method (for hotpluggable bridges) The current MCFG table handling code cannot be easily generalized owing to x86-specific quirks, which makes it hard to reuse on other architectures. Implement generic MCFG handling from scratch, including: - Simple MCFG table parsing (via pci_mmcfg_late_init() as in current x86) - MCFG region lookup for a (domain, bus_start, bus_end) tuple [bhelgaas: changelog] Signed-off-by:
-
dann frazier authored
BugLink: https://bugs.launchpad.net/bugs/1797092Signed-off-by:
-
Jayachandran C authored
BugLink: https://bugs.launchpad.net/bugs/1797092 On platforms with memory-mapped I/O ports, such as ia64 and ARM64, we have to map the memory region and coordinate it with the arch's I/O port accessors. For ia64, we do this in arch code because it supports both dense (1 byte per I/O port) and sparse (1024 bytes per I/O port) memory mapping. For arm64, we only support dense mappings, which we can do in the generic code with pci_register_io_range() and pci_remap_iospace(). Add acpi_pci_root_remap_iospace() to remap dense memory-mapped I/O port space when adding a bridge, and call pci_unmap_iospace() to release the space when removing the bridge. [bhelgaas: changelog, move #ifdef inside acpi_pci_root_remap_iospace()] Signed-off-by:
Sinan Kaya <okaya@codeaurora.org> [Tomasz: merged in Sinan's patch to unmap IO resources properly, updated changelog] Signed-off-by:
-
Sinan Kaya authored
BugLink: https://bugs.launchpad.net/bugs/1797092 Add pci_unmap_iospace() to undo what pci_remap_iospace() did. This is needed to support hotplug removal of host bridges that use pci_remap_iospace(). [bhelgaas: changelog] Signed-off-by:
-
Jayachandran C authored
BugLink: https://bugs.launchpad.net/bugs/1797092 Add a parent device field to struct pci_config_window. The parent is not saved now, but will be useful to save it in some cases. For ACPI on ARM64, it can be used to setup ACPI companion and domain. Since the parent dev is in struct pci_config_window now, we need not pass it to the init function as a separate argument. Signed-off-by:
-
Jayachandran C authored
BugLink: https://bugs.launchpad.net/bugs/1797092 This header will be used from arch/arm64 for ACPI PCI implementation so it needs to be moved out of drivers/pci. Update users of the header file to use the new name. No functional changes. Signed-off-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1797092 No functional changes in this patch. PCI I/O space mapping code does not depend on OF; therefore it can be moved to PCI core code. This way we will be able to use it, e.g., in ACPI PCI code. Suggested-by:
-
Jayachandran C authored
BugLink: https://bugs.launchpad.net/bugs/1797092 Use functions provided by drivers/pci/ecam.h for mapping the config space in drivers/pci/host/pci-host-common.c, and update its users to use 'struct pci_config_window' and 'struct pci_ecam_ops'. The changes are mostly to use 'struct pci_config_window' in place of 'struct gen_pci'. Some of the fields of gen_pci were only used temporarily and can be eliminated by using local variables or function arguments, these are not carried over to struct pci_config_window. pci-thunder-ecam.c and pci-thunder-pem.c are the only users of the pci_host_common_probe function and the gen_pci structure; these have been updated to use the new API as well. The patch does not introduce any functional changes other than a very minor one: with the new code, on 64-bit platforms, we do just a single ioremap for the whole config space. Signed-off-by:
-
Jayachandran C authored
BugLink: https://bugs.launchpad.net/bugs/1797092 Add config option PCI_ECAM and file drivers/pci/ecam.c to provide generic functions for accessing memory-mapped PCI config space. The API is defined in drivers/pci/ecam.h and is written to replace the API in drivers/pci/host/pci-host-common.h. The file defines a new 'struct pci_config_window' to hold the information related to a PCI config area and its mapping. This structure is expected to be used as sysdata for controllers that have ECAM based mapping. Helper functions are provided to setup the mapping, free the mapping and to implement the map_bus method in 'struct pci_ops' Signed-off-by:
-
dann frazier authored
BugLink: https://bugs.launchpad.net/bugs/1797092Signed-off-by:
-
Sai Praneeth authored
BugLink: https://launchpad.net/bugs/1786139 Future Intel processors will support "Enhanced IBRS" which is an "always on" mode i.e. IBRS bit in SPEC_CTRL MSR is enabled once and never disabled. From the specification [1]: "With enhanced IBRS, the predicted targets of indirect branches executed cannot be controlled by software that was executed in a less privileged predictor mode or on another logical processor. As a result, software operating on a processor with enhanced IBRS need not use WRMSR to set IA32_SPEC_CTRL.IBRS after every transition to a more privileged predictor mode. Software can isolate predictor modes effectively simply by setting the bit once. Software need not disable enhanced IBRS prior to entering a sleep state such as MWAIT or HLT." If Enhanced IBRS is supported by the processor then use it as the preferred spectre v2 mitigation mechanism instead of Retpoline. Intel's Retpoline white paper [2] states: "Retpoline is known to be an effective branch target injection (Spectre variant 2) mitigation on Intel processors belonging to family 6 (enumerated by the CPUID instruction) that do not have support for enhanced IBRS. On processors that support enhanced IBRS, it should be used for mitigation instead of retpoline." The reason why Enhanced IBRS is the recommended mitigation on processors which support it is that these processors also support CET which provides a defense against ROP attacks. Retpoline is very similar to ROP techniques and might trigger false positives in the CET defense. If Enhanced IBRS is selected as the mitigation technique for spectre v2, the IBRS bit in SPEC_CTRL MSR is set once at boot time and never cleared. Kernel also has to make sure that IBRS bit remains set after VMEXIT because the guest might have cleared the bit. This is already covered by the existing x86_spec_ctrl_set_guest() and x86_spec_ctrl_restore_host() speculation control functions. Enhanced IBRS still requires IBPB for full mitigation. [1] Speculative-Execution-Side-Channel-Mitigations.pdf [2] Retpoline-A-Branch-Target-Injection-Mitigation.pdf Both documents are available at: https://bugzilla.kernel.org/show_bug.cgi?id=199511Originally-by:
David Woodhouse <dwmw@amazon.co.uk> Signed-off-by:
Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Tim C Chen <tim.c.chen@intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Ravi Shankar <ravi.v.shankar@intel.com> Link: https://lkml.kernel.org/r/1533148945-24095-1-git-send-email-sai.praneeth.prakhya@intel.com (backported from commit 706d5168) [tyhicks: Minor context changes and properly place the check in cpu_set_bug_bits()] Signed-off-by:
-
Jiang Biao authored
BugLink: https://launchpad.net/bugs/1786139 SPECTRE_V2_IBRS in enum spectre_v2_mitigation is never used. Remove it. Signed-off-by:
Jiang Biao <jiang.biao2@zte.com.cn> Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 linux/prefetch.h is never explicitly included in ena_com, although functions from it, such as prefetchw(), are used throughout ena_com. This is an inclusion bug, and we fix it here by explicitly including linux/prefetch.h. The bug was exposed when the driver was compiled for the xtensa architecture. Fixes: 689b2bda ("net: ena: add functions for handling Low Latency Queues in ena_com") Fixes: 8c590f97 ("ena: Fix Kconfig dependency on X86") Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 00f17a82 net-next) Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Use the new API to enable usage of LLQ. Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1798182 The Kconfig limitation of X86 is to too wide. The ENA driver only requires a little endian dependency. Change the dependency to be on little endian CPU. Signed-off-by:
Netanel Belgazal <netanel@amazon.com> Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Remove redundant spinlock acquire parameter from ena_com_admin_init() Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Improves socket memory utilization when receiving packets larger than 128 bytes (the previous rx copybreak) and smaller than 256 bytes. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Currently Rx refill is done when the number of required descriptors is above 1/8 queue size. With a default of 1024 entries per queue the threshold is 128 descriptors. There is intention to increase the queue size to 8196 entries. In this case threshold of 1024 descriptors is too large and can hurt latency. Add another limitation to Rx threshold to be at most 256 descriptors. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Set skb->ip_summed to the correct value as reported by the device. Add counter for the case where rx csum offload is enabled but device didn't check it. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 This patch includes all code changes necessary in ena_netdev to enable packet sending via the LLQ placemnt mode. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 This patch introduces APIs for detection, initialization, configuration and actual usage of low latency queues(LLQ). It extends transmit API with creation of LLQ descriptors in device memory (which include host buffers descriptors as well as packet header) Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Low Latency Queues(LLQ) allow usage of device's memory for descriptors and headers. Such queues decrease processing time since data is already located on the device when driver rings the doorbell. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Add new fields and definitions to host info and fill them according to the latest ENA spec version. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Reduce fastpath overhead by making ena_com_tx_comp_req_id_get() inline. Also move it to ena_eth_com.h file with its dependency function ena_com_cq_inc_head(). Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Eliminate potential auto casting compilation error. Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 napi poll functions should be initialized before running request_irq(), to handle a rare condition where there is a pending interrupt, causing the ISR to fire immediately while the poll function wasn't set yet, causing a NULL dereference. Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 In a rare scenario when ena_device_restore() fails, followed by device remove, an FLR will not be issued. In this case, the device will keep sending asynchronous AENQ keep-alive events, even after driver removal, leading to memory corruption. Fixes: 8c5c7abd ("net: ena: add power management ops to the ENA driver") Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Memory mapped with devm_ioremap is automatically freed when the driver is disconnected from the device. Therefore there is no need to explicitly call devm_iounmap. Fixes: 0857d92f ("net: ena: add missing unmap bars on device removal") Fixes: 411838e7 ("net: ena: fix rare kernel crash when bar memory remap fails") Signed-off-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1798182 As diagnosed by Song Liu, ndo_poll_controller() can be very dangerous on loaded hosts, since the cpu calling ndo_poll_controller() might steal all NAPI contexts (for all RX/TX queues of the NIC). This capture can last for unlimited amount of time, since one cpu is generally not able to drain all the queues under load. ena uses NAPI for TX completions, so we better let core networking stack call the napi->poll() to avoid the capture. Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Netanel Belgazal <netanel@amazon.com> Cc: Saeed Bishara <saeedb@amazon.com> Cc: Zorik Machulsky <zorik@amazon.com> Signed-off-by:
-
