- 01 Jun, 2018 1 commit
-
-
Dave Martin authored
Now that the kernel SVE support is reasonably mature, it is excessive to default sve_max_vl to the invalid value -1 and then sprinkle WARN_ON()s around the place to make sure it has been initialised before use. The cpufeatures code already runs pretty early, and will ensure sve_max_vl gets initialised. This patch initialises sve_max_vl to something sane that will be supported by every SVE implementation, and removes most of the sanity checks. The checks in find_supported_vector_length() are retained for now. If anything goes horribly wrong, we are likely to trip a check here sooner or later. Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Acked-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com>
-
- 31 May, 2018 15 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/will/linuxCatalin Marinas authored
- perf/arm-cci: allow building as module - perf/arm-ccn: demote dev_warn() to dev_dbg() in event_init() - miscellaneous perf/arm cleanups * 'for-next/perf' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux: ARM: mcpm, perf/arm-cci: export mcpm_is_available drivers/bus: arm-cci: fix build warnings drivers/perf: Remove ARM_SPE_PMU explicit PERF_EVENTS dependency drivers/perf: arm-ccn: don't log to dmesg in event_init perf/arm-cci: Allow building as a module perf/arm-cci: Remove pointless PMU disabling perf/arm-cc*: Fix MODULE_LICENSE() tags arm_pmu: simplify arm_pmu::handle_irq perf/arm-cci: Remove unnecessary period adjustment perf: simplify getting .drvdata
-
Marc Zyngier authored
Now that all our infrastructure is in place, let's expose the availability of ARCH_WORKAROUND_2 to guests. We take this opportunity to tidy up a couple of SMCCC constants. Acked-by:
Christoffer Dall <christoffer.dall@arm.com> Reviewed-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Marc Zyngier authored
In order to forward the guest's ARCH_WORKAROUND_2 calls to EL3, add a small(-ish) sequence to handle it at EL2. Special care must be taken to track the state of the guest itself by updating the workaround flags. We also rely on patching to enable calls into the firmware. Note that since we need to execute branches, this always executes after the Spectre-v2 mitigation has been applied. Reviewed-by:
-
Marc Zyngier authored
In order to offer ARCH_WORKAROUND_2 support to guests, we need a bit of infrastructure. Let's add a flag indicating whether or not the guest uses SSBD mitigation. Depending on the state of this flag, allow KVM to disable ARCH_WORKAROUND_2 before entering the guest, and enable it when exiting it. Reviewed-by:
-
Marc Zyngier authored
As we're going to require to access per-cpu variables at EL2, let's craft the minimum set of accessors required to implement reading a per-cpu variable, relying on tpidr_el2 to contain the per-cpu offset. Reviewed-by:
-
Marc Zyngier authored
If running on a system that performs dynamic SSBD mitigation, allow userspace to request the mitigation for itself. This is implemented as a prctl call, allowing the mitigation to be enabled or disabled at will for this particular thread. Acked-by:
-
Marc Zyngier authored
In order to allow userspace to be mitigated on demand, let's introduce a new thread flag that prevents the mitigation from being turned off when exiting to userspace, and doesn't turn it on on entry into the kernel (with the assumption that the mitigation is always enabled in the kernel itself). This will be used by a prctl interface introduced in a later patch. Reviewed-by:
-
Marc Zyngier authored
On a system where firmware can dynamically change the state of the mitigation, the CPU will always come up with the mitigation enabled, including when coming back from suspend. If the user has requested "no mitigation" via a command line option, let's enforce it by calling into the firmware again to disable it. Similarily, for a resume from hibernate, the mitigation could have been disabled by the boot kernel. Let's ensure that it is set back on in that case. Acked-by:
-
Marc Zyngier authored
In order to avoid checking arm64_ssbd_callback_required on each kernel entry/exit even if no mitigation is required, let's add yet another alternative that by default jumps over the mitigation, and that gets nop'ed out if we're doing dynamic mitigation. Think of it as a poor man's static key... Reviewed-by:
Julien Grall <julien.grall@arm.com> Reviewed-by:
-
Marc Zyngier authored
We're about to need the mitigation state in various parts of the kernel in order to do the right thing for userspace and guests. Let's expose an accessor that will let other subsystems know about the state. Reviewed-by:
-
Marc Zyngier authored
On a system where the firmware implements ARCH_WORKAROUND_2, it may be useful to either permanently enable or disable the workaround for cases where the user decides that they'd rather not get a trap overhead, and keep the mitigation permanently on or off instead of switching it on exception entry/exit. In any case, default to the mitigation being enabled. Reviewed-by:
-
Marc Zyngier authored
As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery mechanism for detecting the SSBD mitigation. A new capability is also allocated for that purpose, and a config option. Reviewed-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
-
Marc Zyngier authored
In a heterogeneous system, we can end up with both affected and unaffected CPUs. Let's check their status before calling into the firmware. Reviewed-by:
-
Marc Zyngier authored
In order for the kernel to protect itself, let's call the SSBD mitigation implemented by the higher exception level (either hypervisor or firmware) on each transition between userspace and kernel. We must take the PSCI conduit into account in order to target the right exception level, hence the introduction of a runtime patching callback. Reviewed-by:
-
Marc Zyngier authored
We've so far used the PSCI return codes for SMCCC because they were extremely similar. But with the new ARM DEN 0070A specification, "NOT_REQUIRED" (-2) is clashing with PSCI's "PSCI_RET_INVALID_PARAMS". Let's bite the bullet and add SMCCC specific return codes. Users can be repainted as and when required. Acked-by:
-
- 29 May, 2018 2 commits
-
-
Arnd Bergmann authored
Now that the ARM CCI PMU driver can be built as a loadable module, we get a link failure when MCPM is enabled: ERROR: "mcpm_is_available" [drivers/perf/arm-cci.ko] undefined! The simplest fix is to export that helper function. Fixes: 8b0c93c2 ("perf/arm-cci: Allow building as a module") Acked-by:
Nicolas Pitre <nico@linaro.org> Acked-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
When the arm-cci driver is enabled, but both CONFIG_ARM_CCI5xx_PMU and CONFIG_ARM_CCI400_PMU are not, we get a warning about how parts of the driver are never used: drivers/perf/arm-cci.c:1454:29: error: 'cci_pmu_models' defined but not used [-Werror=unused-variable] drivers/perf/arm-cci.c:693:16: error: 'cci_pmu_event_show' defined but not used [-Werror=unused-function] drivers/perf/arm-cci.c:685:16: error: 'cci_pmu_format_show' defined but not used [-Werror=unused-function] Marking all three functions as __maybe_unused avoids the warnings in randconfig builds. I'm doing this lacking any ideas for a better fix. Fixes: 3de6be7a ("drivers/bus: Split Arm CCI driver") Reviewed-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
- 23 May, 2018 3 commits
-
-
Mark Rutland authored
In do_page_fault(), we handle some kernel faults early, and simply die() with a message. For faults handled later, we dump the faulting address, decode the ESR, walk the page tables, and perform a number of steps to ensure that this data is reported. Let's unify the handling of fatal kernel faults with a new die_kernel_fault() helper, handling all of these details. This is largely the same as the existing logic in __do_kernel_fault(), except that addresses are consistently padded to 16 hex characters, as would be expected for a 64-bit address. The messages currently logged in do_page_fault are adjusted to fit into the die_kernel_fault() message template. Acked-by:
-
Mark Rutland authored
The naming of is_permission_fault() makes it sound like it should return true for permission faults from EL0, but by design, it only does so for faults from EL1. Let's make this clear by dropping el1 in the name, as we do for is_el1_instruction_abort(). Acked-by:
-
Will Deacon authored
Now that we're seeing CPUs shipping with LSE atomics, default them to 'on' in Kconfig. CPUs without the instructions will continue to use LDXR/STXR-based sequences, but they will be placed out-of-line by the compiler. Acked-by:
-
- 22 May, 2018 1 commit
-
-
John Garry authored
Since commit bddb9b68 ("drivers/perf: commonise PERF_EVENTS dependency"), all perf drivers depend on PERF_EVENTS config under a common menu. Config ARM_SPE_PMU still declares explicitly a dependency on PERF_EVENTS, which is unneeded, so remove it. Acked-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
- 21 May, 2018 7 commits
-
-
Mark Rutland authored
The ARM CCN PMU driver uses dev_warn() to complain about parameters in the user-provided perf_event_attr. This means that under normal operation (e.g. a single invocation of the perf tool), a number of messages warnings may be logged to dmesg. Tools may issue multiple syscalls to probe for feature support, and multiple applications (from multiple users) can attempt to open events simultaneously, so this is not very helpful, even if a user happens to have access to dmesg. Worse, this can push important information out of the dmesg ring buffer, and can significantly slow down syscall fuzzers, vastly increasing the time it takes to find critical bugs. Demote the dev_warn() instances to dev_dbg(), as is the case for all other PMU drivers under drivers/perf/. Users who wish to debug PMU event initialisation can enable dynamic debug to receive these messages. Signed-off-by:
-
Robin Murphy authored
Fill in the few extra bits and annotations needed to make the driver work properly as a module, and jiggle the Kconfig to expose the driver-level ARM_CCI_PMU option. Signed-off-by:
-
Robin Murphy authored
The CCI PMU driver bears some legacy remnants of the arm_pmu framework from when it was split in c6f85cb4 ("bus: cci: move away from arm_pmu framework"). In particular this perf_pmu_{dis,en}able() dance around pmu->add which was fixed for arm_pmu in a9e469d1 ("drivers/perf: arm_pmu: remove pointless PMU disabling"). For the exact same reasons (i.e. perf core already does this around the call anyway), give cci_pmu_add() the exact same change, which also prevents having to export those core functions to build it as a module. Acked-by:
-
Robin Murphy authored
The CCI/CCN drivers are licensed under GPLv2, but the MODULE_LICENSE() tags are using the bare "GPL" string implying GPLv2 or later. Fix them to match their actual file license. Acked-by:
Pawel Moll <pawel.moll@arm.com> Acked-by:
-
Mark Rutland authored
The arm_pmu::handle_irq() callback has the same prototype as a generic IRQ handler, taking the IRQ number and a void pointer argument which it must convert to an arm_pmu pointer. This means that all arm_pmu::handle_irq() take an IRQ number they never use, and all must explicitly cast the void pointer to an arm_pmu pointer. Instead, let's change arm_pmu::handle_irq to take an arm_pmu pointer, allowing these casts to be removed. The redundant IRQ number parameter is also removed. Suggested-by:
Hoeun Ryu <hoeun.ryu@lge.com> Signed-off-by:
-
Robin Murphy authored
Since sampling events are rejected up-front by cci_pmu_event_init(), it doesn't make much sense to go fiddling with the sampling period later. This would seem to be just another leftover artefact of the arm_pmu framwork, and as such can go. Acked-by:
-
Wolfram Sang authored
We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
-
- 17 May, 2018 11 commits
-
-
Dave Martin authored
Writes to ZCR_EL1 are self-synchronising, and so may be expensive in typical implementations. This patch adopts the approach used for costly system register writes elsewhere in the kernel: the system register write is suppressed if it would not change the stored value. Since the common case will be that of switching between tasks that use the same vector length as one another, prediction hit rates on the conditional branch should be reasonably good, with lower expected amortised cost than the unconditional execution of a heavyweight self-synchronising instruction. Signed-off-by:
-
Jeremy Linton authored
Now that we have an accurate view of the physical topology we need to represent it correctly to the scheduler. Generally MC should equal the LLC in the system, but there are a number of special cases that need to be dealt with. In the case of NUMA in socket, we need to assure that the sched domain we build for the MC layer isn't larger than the DIE above it. Similarly for LLC's that might exist in cross socket interconnect or directory hardware we need to assure that MC is shrunk to the socket or NUMA node. This patch builds a sibling mask for the LLC, and then picks the smallest of LLC, socket siblings, or NUMA node siblings, which gives us the behavior described above. This is ever so slightly different than the similar alternative where we look for a cache layer less than or equal to the socket/NUMA siblings. The logic to pick the MC layer affects all arm64 machines, but only changes the behavior for DT/MPIDR systems if the NUMA domain is smaller than the core siblings (generally set to the cluster). Potentially this fixes a possible bug in DT systems, but really it only affects ACPI systems where the core siblings is correctly set to the socket siblings. Thus all currently available ACPI systems should have MC equal to LLC, including the NUMA in socket machines where the LLC is partitioned between the NUMA nodes. Tested-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by:
Vijaya Kumar K <vkilari@codeaurora.org> Tested-by:
Xiongfeng Wang <wangxiongfeng2@huawei.com> Tested-by:
Tomasz Nowicki <Tomasz.Nowicki@cavium.com> Acked-by:
Sudeep Holla <sudeep.holla@arm.com> Acked-by:
Morten Rasmussen <morten.rasmussen@arm.com> Signed-off-by:
Jeremy Linton <jeremy.linton@arm.com> Signed-off-by:
-
Jeremy Linton authored
Add ACPI_SIG_PPTT to the table so initrd's can override the system topology. Tested-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Geoffrey Blake <geoffrey.blake@arm.com> Signed-off-by:
-
Jeremy Linton authored
Propagate the topology information from the PPTT tree to the cpu_topology array. We can get the thread id and core_id by assuming certain levels of the PPTT tree correspond to those concepts. The package_id is flagged in the tree and can be found by calling find_acpi_cpu_topology_package() which terminates its search when it finds an ACPI node flagged as the physical package. If the tree doesn't contain enough levels to represent all of the requested levels then the root node will be returned for all subsequent levels. Tested-by:
-
Jeremy Linton authored
The cluster concept isn't architecturally defined for arm64. Lets match the name of the arm64 topology field to the kernel macro that uses it. Tested-by:
-
Jeremy Linton authored
The /sys cache entries should support ACPI/PPTT generated cache topology information. For arm64, if ACPI is enabled, determine the max number of cache levels and populate them using the PPTT table if one is available. Tested-by:
-
Jeremy Linton authored
Call ACPI cache parsing routines from base cacheinfo code if ACPI is enabled. Also stub out cache_setup_acpi and acpi_find_last_cache_level so that individual architectures can enable ACPI topology parsing. Tested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Jeremy Linton authored
Now that we have a PPTT parser, in preparation for its use on arm64, lets build it. Tested-by:
-
Jeremy Linton authored
ACPI 6.2 adds a new table, which describes how processing units are related to each other in tree like fashion. Caches are also sprinkled throughout the tree and describe the properties of the caches in relation to other caches and processing units. Add the code to parse the cache hierarchy and report the total number of levels of cache for a given core using acpi_find_last_cache_level() as well as fill out the individual cores cache information with cache_setup_acpi() once the cpu_cacheinfo structure has been populated by the arch specific code. An additional patch later in the set adds the ability to report peers in the topology using find_acpi_cpu_topology() to report a unique ID for each processing unit at a given level in the tree. These unique id's can then be used to match related processing units which exist as threads, within a given package, etc. Tested-by:
-
Jeremy Linton authored
Its helpful to be able to lookup the acpi_processor_id associated with a logical cpu. Provide an arm64 helper to do this. Tested-by:
-
Jeremy Linton authored
Rename and change the type of of_node to indicate it is a generic pointer which is generally only used for comparison purposes. In a later patch we will put an ACPI/PPTT token pointer in fw_token so that the code which builds the shared cpu masks can be reused. Tested-by:
-
