- 12 Sep, 2024 8 commits
-
-
Will Deacon authored
* for-next/pkvm-guest: arm64: smccc: Reserve block of KVM "vendor" services for pKVM hypercalls drivers/virt: pkvm: Intercept ioremap using pKVM MMIO_GUARD hypercall arm64: mm: Add confidential computing hook to ioremap_prot() drivers/virt: pkvm: Hook up mem_encrypt API using pKVM hypercalls arm64: mm: Add top-level dispatcher for internal mem_encrypt API drivers/virt: pkvm: Add initial support for running as a protected guest firmware/smccc: Call arch-specific hook on discovering KVM services
-
Will Deacon authored
* for-next/perf: (33 commits) perf: arm-ni: Fix an NULL vs IS_ERR() bug perf: arm_pmuv3: Use BR_RETIRED for HW branch event if enabled MAINTAINERS: List Arm interconnect PMUs as supported perf: Add driver for Arm NI-700 interconnect PMU dt-bindings/perf: Add Arm NI-700 PMU perf/arm-cmn: Improve format attr printing perf/arm-cmn: Clean up unnecessary NUMA_NO_NODE check perf/arm-cmn: Support CMN S3 dt-bindings: perf: arm-cmn: Add CMN S3 perf/arm-cmn: Refactor DTC PMU register access perf/arm-cmn: Make cycle counts less surprising perf/arm-cmn: Improve build-time assertion perf/arm-cmn: Ensure dtm_idx is big enough perf/arm-cmn: Fix CCLA register offset perf/arm-cmn: Refactor node ID handling. Again. drivers/perf: hisi_pcie: Export supported Root Ports [bdf_min, bdf_max] drivers/perf: hisi_pcie: Fix TLP headers bandwidth counting drivers/perf: hisi_pcie: Record hardware counts correctly drivers/perf: arm_spe: Use perf_allow_kernel() for permissions perf/dwc_pcie: Add support for QCOM vendor devices ...
-
Will Deacon authored
* for-next/mm: arm64/mm: use lm_alias() with addresses passed to memblock_free() mm: arm64: document why pte is not advanced in contpte_ptep_set_access_flags() arm64: Expose the end of the linear map in PHYSMEM_END arm64: trans_pgd: mark PTEs entries as valid to avoid dead kexec() arm64/mm: Delete __init region from memblock.reserved
-
Will Deacon authored
* for-next/misc: arm64: hibernate: Fix warning for cast from restricted gfp_t arm64: esr: Define ESR_ELx_EC_* constants as UL arm64: Constify struct kobj_type arm64: smp: smp_send_stop() and crash_smp_send_stop() should try non-NMI first arm64/sve: Remove unused declaration read_smcr_features() arm64: mm: Remove unused declaration early_io_map() arm64: el2_setup.h: Rename some labels to be more diff-friendly arm64: signal: Fix some under-bracketed UAPI macros arm64/mm: Drop TCR_SMP_FLAGS arm64/mm: Drop PMD_SECT_VALID
-
Will Deacon authored
* for-next/errata: arm64: errata: Enable the AC03_CPU_38 workaround for ampere1a
-
Will Deacon authored
* for-next/acpi: ACPI/IORT: Add PMCG platform information for HiSilicon HIP10/11 ACPI: ARM64: add acpi_iort.h to MAINTAINERS ACPI/IORT: Switch to use kmemdup_array()
-
Dan Carpenter authored
The devm_ioremap() function never returns error pointers, it returns a NULL pointer if there is an error. Fixes: 4d5a7680 ("perf: Add driver for Arm NI-700 interconnect PMU") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/04d6ccc3-6d31-4f0f-ab0f-7a88342cc09a@stanley.mountainSigned-off-by:
Will Deacon <will@kernel.org>
-
Min-Hua Chen authored
This patch fixes the following warning by adding __force to the cast: arch/arm64/kernel/hibernate.c:410:44: sparse: warning: cast from restricted gfp_t No functional change intended. Signed-off-by:
Min-Hua Chen <minhuadotchen@gmail.com> Link: https://lore.kernel.org/r/20240910232507.313555-1-minhuadotchen@gmail.comSigned-off-by:
-
- 10 Sep, 2024 1 commit
-
-
Anastasia Belova authored
Add explicit casting to prevent expantion of 32th bit of u32 into highest half of u64 in several places. For example, in inject_abt64: ESR_ELx_EC_DABT_LOW << ESR_ELx_EC_SHIFT = 0x24 << 26. This operation's result is int with 1 in 32th bit. While casting this value into u64 (esr is u64) 1 fills 32 highest bits. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: <stable@vger.kernel.org> Fixes: aa8eff9b ("arm64: KVM: fault injection into a guest") Signed-off-by:
Anastasia Belova <abelova@astralinux.ru> Acked-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/stable/20240910085016.32120-1-abelova%40astralinux.ru Link: https://lore.kernel.org/r/20240910085016.32120-1-abelova@astralinux.ruSigned-off-by:
-
- 09 Sep, 2024 1 commit
-
-
Ilkka Koskinen authored
The PMU driver attempts to use PC_WRITE_RETIRED for the HW branch event, if enabled. However, PC_WRITE_RETIRED counts only taken branches, whereas BR_RETIRED counts also non-taken ones. Furthermore, perf uses HW branch event to calculate branch misses ratio, implying BR_RETIRED is the correct event to count. We keep PC_WRITE_RETIRED still as an option in case BR_RETIRED isn't implemented. Signed-off-by:
Ilkka Koskinen <ilkka@os.amperecomputing.com> Link: https://lore.kernel.org/r/20240906191539.4847-1-ilkka@os.amperecomputing.comSigned-off-by:
-
- 06 Sep, 2024 7 commits
-
-
Robin Murphy authored
Whatever I may or may not have hoped for, looking after these drivers seems to have firmly stuck as one of the responsibilities of the job Arm pays me for, and I would still like to be aware of any other patches, so make it official. CC: Ilkka Koskinen <ilkka@os.amperecomputing.com> CC: Jing Zhang <renyu.zj@linux.alibaba.com> Signed-off-by:
-
Robin Murphy authored
The Arm NI-700 Network-on-Chip Interconnect has a relatively straightforward design with a hierarchy of voltage, power, and clock domains, where each clock domain then contains a number of interface units and a PMU which can monitor events thereon. As such, it begets a relatively straightforward driver to interface those PMUs with perf. Even more so than with arm-cmn, users will require detailed knowledge of the wider system topology in order to meaningfully analyse anything, since the interconnect itself cannot know what lies beyond the boundary of each inscrutably-numbered interface. Given that, for now they are also expected to refer to the NI-700 documentation for the relevant event IDs to provide as well. An identifier is implemented so we can come back and add jevents if anyone really wants to. Signed-off-by:
-
Robin Murphy authored
Add an initial binding for the Arm NI-700 interconnect PMU. As with the Arm CMN family, there are already future NI products on the roadmap, so the overall binding is named generically just in case any non-discoverable incompatibility between generations crops up. Cc: devicetree@vger.kernel.org Reviewed-by:
Rob Herring (Arm) <robh@kernel.org> Signed-off-by:
-
Robin Murphy authored
Take full advantage of our formats being stored in bitfield form, and make the printing even more robust and simple by letting printk do all the hard work of formatting bitlists. Signed-off-by:
-
Robin Murphy authored
Checking for NUMA_NO_NODE is a misleading and, on reflection, entirely unnecessary micro-optimisation. If it ever did happen that an incoming CPU has no NUMA affinity while the current CPU does, a questionably- useful PMU migration isn't the biggest thing wrong with that picture... Signed-off-by:
-
Joey Gouly authored
The pointer argument to memblock_free() needs to be a linear map address, but in mem_init() we pass __init_begin/__init_end, which is a kernel image address. This results in warnings when building with CONFIG_DEBUG_VIRTUAL=y: virt_to_phys used for non-linear address: ffff800081270000 (set_reset_devices+0x0/0x10) WARNING: CPU: 0 PID: 1 at arch/arm64/mm/physaddr.c:12 __virt_to_phys+0x54/0x70 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240905 #5810 b1ebb0ad06653f35ce875413d5afad24668df3f3 Hardware name: FVP Base RevC (DT) pstate: 2161402005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __virt_to_phys+0x54/0x70 lr : __virt_to_phys+0x54/0x70 sp : ffff80008169be20 ... Call trace: __virt_to_phys+0x54/0x70 memblock_free+0x18/0x30 free_initmem+0x3c/0x9c kernel_init+0x30/0x1cc ret_from_fork+0x10/0x20 Fix this by having mem_init() convert the pointers via lm_alias(). Fixes: 1db9716d ("arm64/mm: Delete __init region from memblock.reserved") Signed-off-by:Joey Gouly <joey.gouly@arm.com> Suggested-by:
Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Rong Qianfeng <rongqianfeng@vivo.com> Reviewed-by:
-
Barry Song authored
According to David and Ryan, there isn't a bug here, even though we don't advance the PTE entry, because __ptep_set_access_flags() only uses the access flags from the entry. However, we always check pte_same(pte, entry) using the first entry in __ptep_set_access_flags(). This means that the checks from 1 to nr - 1 are not comparing the same PTE indexes (thus, they always return false), which can be a bit confusing. To clarify the code, let's add some comments. Reviewed-by:
Ryan Roberts <ryan.roberts@arm.com> Signed-off-by:
Barry Song <v-songbaohua@oppo.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: David Hildenbrand <david@redhat.com> Cc: Will Deacon <will@kernel.org> Reviewed-by:
David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/20240905081124.9576-1-21cnbao@gmail.comSigned-off-by:
-
- 04 Sep, 2024 11 commits
-
-
D Scott Phillips authored
The memory hot-plug and resource management code needs to know the largest address which can fit in the linear map, so set PHYSMEM_END for that purpose. This fixes a crash at boot when amdgpu tries to create DEVICE_PRIVATE_MEMORY and is given a physical address by the resource management code which is outside the range which can have a `struct page` | Unable to handle kernel paging request at virtual address 000001ffa6000034 | user pgtable: 4k pages, 48-bit VAs, pgdp=000008000287c000 | [000001ffa6000034] pgd=0000000000000000, p4d=0000000000000000 | Call trace: | __init_zone_device_page.constprop.0+0x2c/0xa8 | memmap_init_zone_device+0xf0/0x210 | pagemap_range+0x1e0/0x410 | memremap_pages+0x18c/0x2e0 | devm_memremap_pages+0x30/0x90 | kgd2kfd_init_zone_device+0xf0/0x200 [amdgpu] | amdgpu_device_ip_init+0x674/0x888 [amdgpu] | amdgpu_device_init+0x7a4/0xea0 [amdgpu] | amdgpu_driver_load_kms+0x28/0x1c0 [amdgpu] | amdgpu_pci_probe+0x1a0/0x560 [amdgpu] Signed-off-by:
D Scott Phillips <scott@os.amperecomputing.com> Link: https://lore.kernel.org/r/20240903164532.3874988-1-scott@os.amperecomputing.comSigned-off-by:
-
Fares Mehanna authored
The reasons for PTEs in the kernel direct map to be marked invalid are not limited to kfence / debug pagealloc machinery. In particular, memfd_secret() also steals pages with set_direct_map_invalid_noflush(). When building the transitional page tables for kexec from the current kernel's page tables, those pages need to become regular writable pages, otherwise, if the relocation places kexec segments over such pages, a fault will occur during kexec, leading to host going dark during kexec. This patch addresses the kexec issue by marking any PTE as valid if it is not none. While this fixes the kexec crash, it does not address the security concern that if processes owning secret memory are not terminated before kexec, the secret content will be mapped in the new kernel without being scrubbed. Suggested-by:
Jan H. Schönherr <jschoenh@amazon.de> Signed-off-by:
Fares Mehanna <faresx@amazon.de> Link: https://lore.kernel.org/r/20240902163309.97113-1-faresx@amazon.deSigned-off-by:
-
Rong Qianfeng authored
If CONFIG_ARCH_KEEP_MEMBLOCK is enabled, the memory information in memblock will be retained. We release the __init memory here, and we should also delete the corresponding region in memblock.reserved, which allows debugfs/memblock/reserved to display correct memory information. Signed-off-by:
Rong Qianfeng <rongqianfeng@vivo.com> Link: https://lore.kernel.org/r/20240902023940.43227-1-rongqianfeng@vivo.comSigned-off-by:
-
Robin Murphy authored
CMN S3 is the latest and greatest evolution for 2024, although most of the new features don't impact the PMU, so from our point of view it ends up looking a lot like CMN-700 r3 still. We have some new device types to ignore, a mildly irritating rearrangement of the register layouts, and a scary new configuration option that makes it potentially unsafe to even walk the full discovery tree, let alone attempt to use the PMU. Acked-by:
-
Robin Murphy authored
The CMN S3 PMU is functionally still very similar to CMN-700, however while the register contents are compatible, many of them are moved to different offsets. While this is technically discoverable by a careful driver that understands the part number in the peripheral ID registers (which do at least remain in the same place), a new unique compatible seems warranted to avoid any surprises. CC: devicetree@vger.kernel.org Acked-by:
-
Robin Murphy authored
Annoyingly, we're soon going to have to cope with PMU registers moving about. This will mostly be straightforward, except for the hard-coding of CMN_PMU_OFFSET for the DTC PMU registers. As a first step, refactor those accessors to allow for encapsulating a variable offset without making a big mess all over. As a bonus, we can repack the arm_cmn_dtc structure to accommodate the new pointer without growing any larger, since irq_friend only encodes a range of +/-3. Acked-by:
-
Robin Murphy authored
By default, CMN has automatic clock-gating with the implication that a DTC's cycle counter may not increment while the DTC is sufficiently idle. Given that we may have up to 4 DTCs to choose from when scheduling a cycles event, this may potentially lead to surprising results if trying to measure metrics based on activity in a different DTC domain from where cycles end up being counted. Furthermore, since the details of internal clock gating are not documented, we can't even reason about what "active" cycles for a DTC actually mean relative to the activity of other nodes within the same nominal DTC domain. Make the reasonable assumption that if the user wants to count cycles, they almost certainly want to count all of the cycles, and disable clock gating while a DTC's cycle counter is in use. Signed-off-by:
-
Robin Murphy authored
These days we can use static_assert() in the logical place rather than jamming a BUILD_BUG_ON() into the nearest function scope. Signed-off-by:
-
Robin Murphy authored
While CMN_MAX_DIMENSION was bumped to 12 for CMN-650, that only supports up to a 10x10 mesh, so bumping dtm_idx to 256 bits at the time worked out OK in practice. However CMN-700 did finally support up to 144 XPs, and thus needs a worst-case 288 bits of dtm_idx for an aggregated XP event on a maxed-out config. Oops. Fixes: 23760a01 ("perf/arm-cmn: Add CMN-700 support") Signed-off-by:
-
Robin Murphy authored
Apparently pmu_event_sel is offset by 8 for all CCLA nodes, not just the CCLA_RNI combination type. Fixes: 23760a01 ("perf/arm-cmn: Add CMN-700 support") Acked-by:
-
Robin Murphy authored
The scope of the "extra device ports" configuration is not made clear by the CMN documentation - so far we've assumed it applies globally, based on the sole example which suggests as much. However it transpires that this is incorrect, and the format does in fact vary based on each individual XP's port configuration. As a consequence, we're currenly liable to decode the port/device indices from a node ID incorrectly, thus program the wrong event source in the DTM leading to bogus event counts, and also show device topology on the wrong ports in debugfs. To put this right, rework node IDs yet again to carry around the additional data necessary to decode them properly per-XP. At this point the notion of fully decomposing an ID becomes more impractical than it's worth, so unabstracting the XY mesh coordinates (where 2/3 users were just debug anyway) ends up leaving things a bit simpler overall. Fixes: 60d15040 ("perf/arm-cmn: Support new IP features") Acked-by:
-
- 30 Aug, 2024 12 commits
-
-
Will Deacon authored
pKVM relies on hypercalls to expose services such as memory sharing to protected guests. Tentatively allocate a block of 58 hypercalls (i.e. fill the remaining space in the first 64 function IDs) for pKVM usage, as future extensions such as pvIOMMU support, range-based memory sharing and validation of assigned devices will require additional services. Suggested-by:
-
Will Deacon authored
Hook up pKVM's MMIO_GUARD hypercall so that ioremap() and friends will register the target physical address as MMIO with the hypervisor, allowing guest exits to that page to be emulated by the host with full syndrome information. Acked-by:
-
Will Deacon authored
Confidential Computing environments such as pKVM and Arm's CCA distinguish between shared (i.e. emulated) and private (i.e. assigned) MMIO regions. Introduce a hook into our implementation of ioremap_prot() so that MMIO regions can be shared if necessary. Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Reviewed-by:
Steven Price <steven.price@arm.com> Acked-by:
-
Will Deacon authored
If we detect the presence of pKVM's SHARE and UNSHARE hypercalls, then register a backend implementation of the mem_encrypt API so that things like DMA buffers can be shared appropriately with the host. Acked-by:
-
Will Deacon authored
Implementing the internal mem_encrypt API for arm64 depends entirely on the Confidential Computing environment in which the kernel is running. Introduce a simple dispatcher so that backend hooks can be registered depending upon the environment in which the kernel finds itself. Reviewed-by:
-
Will Deacon authored
Implement a pKVM protected guest driver to probe the presence of pKVM and determine the memory protection granule using the HYP_MEMINFO hypercall. Acked-by:
-
Marc Zyngier authored
arm64 will soon require its own callback to initialise services that are only available on this architecture. Introduce a hook that can be overloaded by the architecture. Signed-off-by:
-
D Scott Phillips authored
The ampere1a cpu is affected by erratum AC04_CPU_10 which is the same bug as AC03_CPU_38. Add ampere1a to the AC03_CPU_38 workaround midr list. Cc: <stable@vger.kernel.org> Signed-off-by:
Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20240827211701.2216719-1-scott@os.amperecomputing.comSigned-off-by:
-
Yicong Yang authored
Currently users can get the Root Ports supported by the PCIe PMU by "bus" sysfs attributes which indicates the PCIe bus number where Root Ports are located. This maybe insufficient since Root Ports supported by different PCIe PMUs may be located on the same PCIe bus. So export the BDF range the Root Ports additionally. Signed-off-by:
Yicong Yang <yangyicong@hisilicon.com> Acked-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20240829090332.28756-4-yangyicong@huawei.comSigned-off-by:
-
Yicong Yang authored
We make the initial value of event ctrl register as HISI_PCIE_INIT_SET and modify according to the user options. This will make TLP headers bandwidth only counting never take effect since HISI_PCIE_INIT_SET configures to count the TLP payloads bandwidth. Fix this by making the initial value of event ctrl register as 0. Fixes: 17d57398 ("drivers/perf: hisi: Add TLP filter support") Signed-off-by:
-
Yicong Yang authored
Currently we set the period and record it as the initial value of the counter without checking it's set to the hardware successfully or not. However the counter maybe unwritable if the target event is unsupported by the device. In such case we will pass user a wrong count: [start counts when setting the period] hwc->prev_count = 0x8000000000000000 device.counter_value = 0 // the counter is not set as the period [when user reads the counter] event->count = device.counter_value - hwc->prev_count = 0x8000000000000000 // wrong. should be 0. Fix this by record the hardware counter counts correctly when setting the period. Fixes: 8404b0fb ("drivers/perf: hisi: Add driver for HiSilicon PCIe PMU") Signed-off-by: -
James Clark authored
Use perf_allow_kernel() for 'pa_enable' (physical addresses), 'pct_enable' (physical timestamps) and context IDs. This means that perf_event_paranoid is now taken into account and LSM hooks can be used, which is more consistent with other perf_event_open calls. For example PERF_SAMPLE_PHYS_ADDR uses perf_allow_kernel() rather than just perfmon_capable(). This also indirectly fixes the following error message which is misleading because perf_event_paranoid is not taken into account by perfmon_capable(): $ perf record -e arm_spe/pa_enable/ Error: Access to performance monitoring and observability operations is limited. Consider adjusting /proc/sys/kernel/perf_event_paranoid setting ... Suggested-by:
Al Grant <al.grant@arm.com> Signed-off-by:
James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20240827145113.1224604-1-james.clark@linaro.org Link: https://lore.kernel.org/all/20240807120039.GD37996@noisy.programming.kicks-ass.net/Signed-off-by:
-
