FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F13.2.0 2021-11-01T14:02:41Z 2021-11-01T14:02:41Z Mark Johnston markj@FreeBSD.org 2021-04-13T21:39:35Z urn:sha1:65f3c07b989942897fbc8991ad3887ab4e1440a2 - Initialize KASAN before executing SYSINITs. - Add a GENERIC-KASAN kernel config, akin to GENERIC-KCSAN. - Increase the kernel stack size if KASAN is enabled. Some of the ASAN instrumentation increases stack usage and it's enough to trigger stack overflows in ZFS. - Mark the trapframe as valid in interrupt handlers if it is assigned to td_intr_frame. Otherwise, an interrupt in a function which creates a poisoned alloca region can trigger false positives. Sponsored by: The FreeBSD Foundation (cherry picked from commit f115c0612131d8f939f6f357f57bdd85bd6a59de) 2020-09-01T21:16:54Z Mateusz Guzik mjg@FreeBSD.org 2020-09-01T21:16:54Z urn:sha1:543769bf83775641c1a7f3d3d86744c7e1f5af4e 2020-08-23T20:19:04Z Konstantin Belousov kib@FreeBSD.org 2020-08-23T20:19:04Z urn:sha1:9ce875d9b59dde81bf116d24e6b8649075674303 Since LA57 was moved to the main SDM document with revision 072, it seems that we should have a support for it, and silicons are coming. This patch makes pmap support both LA48 and LA57 hardware. The selection of page table level is done at startup, kernel always receives control from loader with 4-level paging. It is not clear how UEFI spec would adapt LA57, for instance it could hand out control in LA57 mode sometimes. To switch from LA48 to LA57 requires turning off long mode, requesting LA57 in CR4, then re-entering long mode. This is somewhat delicate and done in pmap_bootstrap_la57(). AP startup in LA57 mode is much easier, we only need to toggle a bit in CR4 and load right value in CR3. I decided to not change kernel map for now. Single PML5 entry is created that points to the existing kernel_pml4 (KML4Phys) page, and a pml5 entry to create our recursive mapping for vtopte()/vtopde(). This decision is motivated by the fact that we cannot overcommit for KVA, so large space there is unusable until machines start providing wider physical memory addressing. Another reason is that I do not want to break our fragile autotuning, so the KVA expansion is not included into this first step. Nice side effect is that minidumps are compatible. On the other hand, (very) large address space is definitely immediately useful for some userspace applications. For userspace, numbering of pte entries (or page table pages) is always done for 5-level structures even if we operate in 4-level mode. The pmap_is_la57() function is added to report the mode of the specified pmap, this is done not to allow simultaneous 4-/5-levels (which is not allowed by hw), but to accomodate for EPT which has separate level control and in principle might not allow 5-leve EPT despite x86 paging supports it. Anyway, it does not seems critical to have 5-level EPT support now. Tested by: pho (LA48 hardware) Reviewed by: alc Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D25273 2020-02-05T19:08:21Z Mark Johnston markj@FreeBSD.org 2020-02-05T19:08:21Z urn:sha1:c3d326fd44d9cf4649aa35a62a2766155c8b383d This reverts r177661. The change is no longer very useful since out-of-tree KLDs will be built to target SMP kernels anyway. Moveover it breaks the KBI in !SMP builds since cpuset_t's layout depends on the value of MAXCPU, and several kernel interfaces, notably smp_rendezvous_cpus(), take a cpuset_t as a parameter. PR: 243711 Reviewed by: jhb, kib Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D23512 2017-11-18T14:26:50Z Pedro F. Giffuni pfg@FreeBSD.org 2017-11-18T14:26:50Z urn:sha1:df57947f083046d50552e99b91074927d2458708 The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. Special thanks to Wind River for providing access to "The Duke of Highlander" tool: an older (2014) run over FreeBSD tree was useful as a starting point. Initially, only tag files that use BSD 4-Clause "Original" license. RelNotes: yes Differential Revision: https://reviews.freebsd.org/D13133 2017-10-22T20:43:50Z Mateusz Guzik mjg@FreeBSD.org 2017-10-22T20:43:50Z urn:sha1:9e6898976483f67381fe01d4be6ab53cbe6fc30c While here cache-align chains. This shortens longest found chain during poudriere -j 80 from 32 to 16. Pushing this higher up will probably require allocation on boot. 2017-08-28T22:28:41Z Conrad Meyer cem@FreeBSD.org 2017-08-28T22:28:41Z urn:sha1:2744a0b69b2ee4c96e87242720907184a3380c56 The actual cache line size has always been 64 bytes. The 128 number arose as an optimization for Core 2 era Intel processors. By default (configurable in BIOS), these CPUs would prefetch adjacent cache lines unintelligently. Newer CPUs prefetch more intelligently. The latest Core 2 era CPU was introduced in September 2008 (Xeon 7400 series, "Dunnington"). If you are still using one of these CPUs, especially in a multi-socket configuration, consider locating the "adjacent cache line prefetch" option in BIOS and disabling it. Reported by: mjg Reviewed by: np Discussed with: jhb Sponsored by: Dell EMC Isilon 2016-04-12T21:23:44Z John Baldwin jhb@FreeBSD.org 2016-04-12T21:23:44Z urn:sha1:7ecf8cab6f4b3c8cb2c2a551e03b3c617d7d628d 8 memory domains should handle a quad-socket board with dual-domain processors. Reviewed by: kib Relnotes: maybe? Differential Revision: https://reviews.freebsd.org/D5893 2015-07-02T14:37:21Z Konstantin Belousov kib@FreeBSD.org 2015-07-02T14:37:21Z urn:sha1:6fdfd88220a1728eca98f1172a09a6782b20cb78 macros on amd64 and i386. Move the definition to machine/param.h. kgdb defines INKERNEL() too, the conflict is resolved by renaming kgdb version to PINKERNEL(). On i386, correct the lowest kernel address. After the shared page was introduced, USRSTACK no longer points to the last user address + 1 [*] Submitted by: Oliver Pinter [*] Sponsored by: The FreeBSD Foundation MFC after: 1 week 2014-08-20T16:06:24Z John Baldwin jhb@FreeBSD.org 2014-08-20T16:06:24Z urn:sha1:64d6de263bdd852cb17ae572aaaef5c10385f481 CPUs (IDs 0 through 254). Getting above that limit requires x2APIC. MFC after: 1 month