- 13 Nov, 2018 40 commits
-
-
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 <tn@semihalf.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> (cherry picked from commit 1a4f93f7) 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:
Khalid Elmously <khalid.elmously@canonical.com>
-
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:
Jayachandran C <jchandra@broadcom.com> 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:
Tyler Hicks <tyhicks@canonical.com> Acked-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:
Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 00f17a82 net-next) Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-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:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1801900Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Signed-off-by:
-
Long Li authored
BugLink: https://bugs.launchpad.net/bugs/1801900 commit a3ade8cc upstream. The host may send multiple negotiation packets (due to timeout) before the KVP user-mode daemon is connected. KVP user-mode daemon is connected. We need to defer processing those packets until the daemon is negotiated and connected. It's okay for guest to respond to all negotiation packets. In addition, the host may send multiple staged KVP requests as soon as negotiation is done. We need to properly process those packets using one tasklet for exclusive access to ring buffer. This patch is based on the work of Nick Meier <Nick.Meier@microsoft.com>. The above is the original changelog of a3ade8cc ("HV: properly delay KVP packets when negotiation is in progress" Here I re-worked the original patch because the mainline version can't work for the linux-4.4.y branch, on which channel->callback_event doesn't exist yet. In the mainline, channel->callback_event was added by: 631e63a9 ("vmbus: change to per channel tasklet"). Here we don't want to backport it to v4.4, as it requires extra supporting changes and fixes, which are unnecessary as to the KVP bug we're trying to resolve. NOTE: before this patch is used, we should cherry-pick the other related 3 patches from the mainline first: The background of this backport request is that: recently Wang Jian reported some KVP issues: https://github.com/LIS/lis-next/issues/593: e.g. the /var/lib/hyperv/.kvp_pool_* files can not be updated, and sometimes if the hv_kvp_daemon doesn't timely start, the host may not be able to query the VM's IP address via KVP. Reported-by:
Wang Jian <jianjian.wang1@gmail.com> Tested-by:
Dexuan Cui <decui@microsoft.com> Signed-off-by:
Long Li <longli@microsoft.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Stephen Warren authored
BugLink: https://bugs.launchpad.net/bugs/1801900 commit daa35bd9 upstream. When the gadget serial device has no associated TTY, do not pass any received data into the TTY layer for processing; simply drop it instead. This prevents the TTY layer from calling back into the gadget serial driver, which will then crash in e.g. gs_write_room() due to lack of gadget serial device to TTY association (i.e. a NULL pointer dereference). Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Alexey Brodkin authored
BugLink: https://bugs.launchpad.net/bugs/1801900 commit 615f6445 upstream. This check is very naive: we simply test if GCC invoked without "-mcpu=XXX" has ARC700 define set. In that case we think that GCC was built with "--with-cpu=arc700" and has libgcc built for ARC700. Otherwise if ARC700 is not defined we think that everythng was built for ARCv2. But in reality our life is much more interesting. 1. Regardless of GCC configuration (i.e. what we pass in "--with-cpu" it may generate code for any ARC core). 2. libgcc might be built with explicitly specified "--mcpu=YYY" That's exactly what happens in case of multilibbed toolchains: - GCC is configured with default settings - All the libs built for many different CPU flavors I.e. that check gets in the way of usage of multilibbed toolchains. And even non-multilibbed toolchains are affected. OpenEmbedded also builds GCC without "--with-cpu" because each and every target component later is compiled with explicitly set "-mcpu=ZZZ". Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Michael Neuling authored
BugLink: https://bugs.launchpad.net/bugs/1801900 [ Upstream commit 96dc89d5 ] Current we store the userspace r1 to PACATMSCRATCH before finally saving it to the thread struct. In theory an exception could be taken here (like a machine check or SLB miss) that could write PACATMSCRATCH and hence corrupt the userspace r1. The SLB fault currently doesn't touch PACATMSCRATCH, but others do. We've never actually seen this happen but it's theoretically possible. Either way, the code is fragile as it is. This patch saves r1 to the kernel stack (which can't fault) before we turn MSR[RI] back on. PACATMSCRATCH is still used but only with MSR[RI] off. We then copy r1 from the kernel stack to the thread struct once we have MSR[RI] back on. Suggested-by:
Breno Leitao <leitao@debian.org> Signed-off-by:
Michael Neuling <mikey@neuling.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
-
Michael Neuling authored
BugLink: https://bugs.launchpad.net/bugs/1801900 [ Upstream commit cf13435b ] When we treclaim we store the userspace checkpointed r13 to a scratch SPR and then later save the scratch SPR to the user thread struct. Unfortunately, this doesn't work as accessing the user thread struct can take an SLB fault and the SLB fault handler will write the same scratch SPRG that now contains the userspace r13. To fix this, we store r13 to the kernel stack (which can't fault) before we access the user thread struct. Found by running P8 guest + powervm + disable_1tb_segments + TM. Seen as a random userspace segfault with r13 looking like a kernel address. Signed-off-by:
-
