FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F14.3.0 2025-03-15T07:05:23Z 2025-03-15T07:05:23Z Ka Ho Ng khng@FreeBSD.org 2025-02-06T21:26:03Z urn:sha1:fa301530e0ca3a762c5dbf0bb8f3411ea5ba0e13 Obtained from: Juniper Networks, Inc. MFC after: 1 week Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D44764 (cherry picked from commit 5484c3d6eb31a78f07ed5e66862a1e7d3b5225b6) 2025-01-16T18:06:53Z Olivier Certner olce@FreeBSD.org 2024-07-19T15:23:19Z urn:sha1:1fc5db8e9f4b10fed01fc1c07d0e5725c4089b97 In order to match reality, allow using these functions with pointers on const objects, and bring us closer to C11. Remove the '+' modifier in the atomic_load_acq_64_i586()'s inline asm statement's constraint for '*p' (the value to load). CMPXCHG8B always writes back some value, even when the value exchange does not happen in which case what was read is written back. atomic_load_acq_64_i586() further takes care of the operation atomically writing back the same value that was read in any case. All in all, this makes the inline asm's write back undetectable by any other code, whether executing on other CPUs or code on the same CPU before and after the call to atomic_load_acq_64_i586(), except for the fact that CMPXCHG8B will trigger a #GP(0) if the memory address is part of a read-only mapping. This unfortunate property is however out of scope of the C abstract machine, and in particular independent of whether the 'uint64_t' pointed to is declared 'const' or not. Approved by: markj (mentor) MFC after: 5 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D46887 (cherry picked from commit 5e9a82e898d55816c366cfa3ffbca84f02569fe5) 2024-12-01T02:46:08Z John Baldwin jhb@FreeBSD.org 2024-11-19T15:24:50Z urn:sha1:b291c7168a7840a74c4e976a91dec21ff0f1e4ce For current architectures, these are just aliases for the existing operation on the relevant scalar integer. Reviewed by: imp, kib Obtained from: CheriBSD Sponsored by: AFRL, DARPA Differential Revision: https://reviews.freebsd.org/D47631 (cherry picked from commit a80b9ee15aa0f2da9f9f0c48e13324e0e5f2e840) 2024-10-21T15:03:27Z Andrew Turner andrew@FreeBSD.org 2024-10-15T08:30:17Z urn:sha1:ce5a07a9d2c58b65bbce5609834af63c5ff7e85d While here make it return void, we don't set any useful return value and nothing checks for it. Sponsored by: Arm Ltd (cherry picked from commit a7c5c88cb29ff512467a6599f1b4d8e2b8817480) 2024-10-21T15:03:27Z Andrew Turner andrew@FreeBSD.org 2024-09-27T14:06:03Z urn:sha1:1f9635e2c213368cfed3737970f3814fbb55a922 Report when SVE is present and allow it to be used by calling sve_restore_state on an SVE exception from userspace. Reviewed by: kib Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D43310 (cherry picked from commit 205c1007be6d57b2eb8620f79384cb2299dde40e) 2024-10-21T15:03:27Z Andrew Turner andrew@FreeBSD.org 2024-09-27T13:41:08Z urn:sha1:a16f10ab0aa76d88cc45cc01fae44b94d1873bbc As with floating point instructions don't trap SVE instructions to the hypervisor. This lets us handle then in the kernel. Reviewed by: imp (earlier version) Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D43303 (cherry picked from commit fe5ed2496e44aec018a6215175bba225b20d81fd) 2024-10-21T15:03:27Z Andrew Turner andrew@FreeBSD.org 2024-09-27T13:37:17Z urn:sha1:f7caa6fb7489b7e9721f064e39050614ae0fc875 Add the NT_ARM_SVE note type and use it to access the SVE registers from ptrace. This allows userspace to modify the full SVE register values. Try to follow the Linux semantics to allow debuggers to use this with minimal changes. Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D43309 (cherry picked from commit aab60068943d733b0b4573e5481c543ab3d45a00) 2024-10-21T15:03:26Z Andrew Turner andrew@FreeBSD.org 2024-09-27T13:37:10Z urn:sha1:aa594ddcc85459ed342694816df26434e96ba88a To allow for user space to read the SVE vector length add a sysarch handler to return the value to userspace. Reviewed by: imp Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D43308 (cherry picked from commit 87a58d931db7b40d8d225a7edb82b78937078b7f) 2024-10-21T15:03:26Z Andrew Turner andrew@FreeBSD.org 2024-09-27T13:37:03Z urn:sha1:7588c7024ed9b3d9845529edd56e46b675430a02 Use the new extended register support in the arm64 signal frame to handle the SVE registers. As these registers alias the VFP registers we use the floating point register values to restore the lower bits of the SVE registers. This is to support software that doesn't understand SVE to continue working. Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D43307 (cherry picked from commit e45132e978030f0aa964d975a9fbad5614f260bd) 2024-10-21T15:03:26Z Andrew Turner andrew@FreeBSD.org 2024-09-27T13:36:35Z urn:sha1:2c5961fff4e5f31079d69e57105132ef9685ca53 Add initial kernel support for SVE. This detects if SVE is present on all CPUs, and if so allows for the use of SVE in the future. As the SVE registers are a superset of the VFP registers we don't need to restore the VFP registers when SVE is enabled. Ths interface to enable SVE is provided, but not used until SVE is supported in signals and with ptrace. Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D43306 (cherry picked from commit 332c426328dbb30a6b2e69d9b1e8298d77d85bd1)