en Copyright 2015 Java http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#2ff63af9 sys: Remove $FreeBSD$: one-line .h patternRemove /^\s*\*+\s*\$FreeBSD\$.*$\n/ List of files: /freebsd-14.2/sys/amd64/include/param.h Wed, 16 Aug 2023 17:54:18 +0000 Warner Losh <imp@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#9051987e amd64: Bump MAXCPU to 1024 (from 256)Hardware with more than 256 CPU cores is currently available and willbecome increasingly common over FreeBSD 14's lifetime. Increase MAXCPUin the amd64 GENERIC kernel configuration to 1024.Earlier commits increased some related limits. These prerequisitecommits include at least:- d7ed40243769 Increase MAX_APIC_ID safeguard to 0x800- d1639e43c589 cpuset: increase userland maximum size to 1024Global and allocated arrays sized by MAXCPU result in excessive bloaton systems with lower core counts. In addition, some code used u_char(8 bits) to hold a CPU index, which is not valid if MAXCPU is greaterthan 256.A number of recent commits addressed these sorts of issues, includingat least:- 133935d26f20 pf: atomically increment state ids- 74ac712f72cf vmm: Dynamically allocate a couple of per-CPU state save areas- 78cfa762ebf2 callout: Move per-CPU callout state into the dpcpu region- 42f722e721cd amd64: store pcids pmap data in pcpu zone- 9801e7c275f6 smp_topo: dynamically allocate group array- 9fb6718d1b18 smp: Dynamically allocate the stoppcbs array- 2bb16c635249 x86: retire use of intr_bindThere are some additional allocations still to be converted andmore scalability work is required to make effective use of very highcore count systems, but this change allows us to boot on these systemsand provides a Kernel Binary Interface (KBI) for the FreeBSD 14 releasethat supports these configurations.Special thanks to AMD for providing hardware to test these changes.PR: 269572Reviewed by: desRelnotes: YesSponsored by: The FreeBSD FoundationDifferential Revision: https://reviews.freebsd.org/D36838 List of files: /freebsd-14.2/sys/amd64/include/param.h Fri, 30 Sep 2022 12:14:22 +0000 Ed Maste <emaste@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#89786088 amd64: Populate the KMSAN shadow maps and integrate with the VM- During boot, allocate PDP pages for the shadow maps. The region above KERNBASE is currently not shadowed.- Create a dummy shadow for the vm page array. For now, this array is not protected by the shadow map to help reduce kernel memory usage.- Grow shadows when growing the kernel map.- Increase the default kernel stack size when KMSAN is enabled. As with KASAN, sanitizer instrumentation appears to create stack frames large enough that the default value is not sufficient.- Disable UMA's use of the direct map when KMSAN is configured. KMSAN cannot validate the direct map.- Disable unmapped I/O when KMSAN configured.- Lower the limit on paging buffers when KMSAN is configured. Each buffer has a static MAXPHYS-sized allocation of KVA, which in turn eats 2*MAXPHYS of space in the shadow map.Reviewed by: alc, kibSponsored by: The FreeBSD FoundationDifferential Revision: https://reviews.freebsd.org/D31295 List of files: /freebsd-14.2/sys/amd64/include/param.h Tue, 10 Aug 2021 20:52:36 +0000 Mark Johnston <markj@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#f115c061 amd64: Add MD bits for KASAN- 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.MFC after: 2 weeksSponsored by: The FreeBSD FoundationDifferential Revision: https://reviews.freebsd.org/D29455 List of files: /freebsd-14.2/sys/amd64/include/param.h Tue, 13 Apr 2021 21:39:35 +0000 Mark Johnston <markj@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#543769bf amd64: clean up empty lines in .c and .h files List of files: /freebsd-14.2/sys/amd64/include/param.h Tue, 01 Sep 2020 21:16:54 +0000 Mateusz Guzik <mjg@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#9ce875d9 amd64 pmap: LA57 AKA 5-level pagingSince LA57 was moved to the main SDM document with revision 072, itseems that we should have a support for it, and silicons are coming.This patch makes pmap support both LA48 and LA57 hardware. Theselection of page table level is done at startup, kernel alwaysreceives control from loader with 4-level paging. It is not clear howUEFI spec would adapt LA57, for instance it could hand out control inLA57 mode sometimes.To switch from LA48 to LA57 requires turning off long mode, requestingLA57 in CR4, then re-entering long mode. This is somewhat delicateand done in pmap_bootstrap_la57(). AP startup in LA57 mode is mucheasier, 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 iscreated that points to the existing kernel_pml4 (KML4Phys) page, and apml5 entry to create our recursive mapping for vtopte()/vtopde().This decision is motivated by the fact that we cannot overcommit forKVA, so large space there is unusable until machines start providingwider physical memory addressing. Another reason is that I do notwant to break our fragile autotuning, so the KVA expansion is notincluded into this first step. Nice side effect is that minidumps arecompatible.On the other hand, (very) large address space is definitelyimmediately useful for some userspace applications.For userspace, numbering of pte entries (or page table pages) isalways 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 thespecified pmap, this is done not to allow simultaneous 4-/5-levels(which is not allowed by hw), but to accomodate for EPT which hasseparate level control and in principle might not allow 5-leve EPTdespite x86 paging supports it. Anyway, it does not seems critical tohave 5-level EPT support now.Tested by: pho (LA48 hardware)Reviewed by: alcSponsored by: The FreeBSD FoundationDifferential revision: https://reviews.freebsd.org/D25273 List of files: /freebsd-14.2/sys/amd64/include/param.h Sun, 23 Aug 2020 20:19:04 +0000 Konstantin Belousov <kib@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#c3d326fd Define MAXCPU consistently between the kernel and KLDs.This reverts r177661. The change is no longer very useful sinceout-of-tree KLDs will be built to target SMP kernels anyway. Moveoverit breaks the KBI in !SMP builds since cpuset_t's layout depends on thevalue of MAXCPU, and several kernel interfaces, notablysmp_rendezvous_cpus(), take a cpuset_t as a parameter.PR: 243711Reviewed by: jhb, kibSponsored by: The FreeBSD FoundationDifferential Revision: https://reviews.freebsd.org/D23512 List of files: /freebsd-14.2/sys/amd64/include/param.h Wed, 05 Feb 2020 19:08:21 +0000 Mark Johnston <markj@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#df57947f spdx: initial adoption of licensing ID tags.The Software Package Data Exchange (SPDX) group provides a specificationto make it easier for automated tools to detect and summarize well knownopensource licenses. We are gradually adopting the specification, notingthat 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 ofHighlander" tool: an older (2014) run over FreeBSD tree was useful as astarting point.Initially, only tag files that use BSD 4-Clause "Original" license.RelNotes: yesDifferential Revision: https://reviews.freebsd.org/D13133 List of files: /freebsd-14.2/sys/amd64/include/param.h Sat, 18 Nov 2017 14:26:50 +0000 Pedro F. Giffuni <pfg@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#9e689897 Make the sleepq chain hash size configurable per-arch and bump on amd64.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. List of files: /freebsd-14.2/sys/amd64/include/param.h Sun, 22 Oct 2017 20:43:50 +0000 Mateusz Guzik <mjg@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#2744a0b6 Drop CACHE_LINE_SIZE to 64 bytes on x86The actual cache line size has always been 64 bytes.The 128 number arose as an optimization for Core 2 era Intel processors. Bydefault (configurable in BIOS), these CPUs would prefetch adjacent cachelines unintelligently. Newer CPUs prefetch more intelligently.The latest Core 2 era CPU was introduced in September 2008 (Xeon 7400series, "Dunnington"). If you are still using one of these CPUs, especiallyin a multi-socket configuration, consider locating the "adjacent cache lineprefetch" option in BIOS and disabling it.Reported by: mjgReviewed by: npDiscussed with: jhbSponsored by: Dell EMC Isilon List of files: /freebsd-14.2/sys/amd64/include/param.h Mon, 28 Aug 2017 22:28:41 +0000 Conrad Meyer <cem@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#7ecf8cab Enable DEVICE_NUMA with up to 8 domains by default on amd64.8 memory domains should handle a quad-socket board with dual-domainprocessors.Reviewed by: kibRelnotes: maybe?Differential Revision: https://reviews.freebsd.org/D5893 List of files: /freebsd-14.2/sys/amd64/include/param.h Tue, 12 Apr 2016 21:23:44 +0000 John Baldwin <jhb@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#6fdfd882 Use single instance of the identical INKERNEL() and PMC_IN_KERNEL()macros on amd64 and i386. Move the definition to machine/param.h.kgdb defines INKERNEL() too, the conflict is resolved by renaming kgdbversion to PINKERNEL().On i386, correct the lowest kernel address. After the shared page wasintroduced, USRSTACK no longer points to the last user address + 1 [*]Submitted by: Oliver Pinter [*]Sponsored by: The FreeBSD FoundationMFC after: 1 week List of files: /freebsd-14.2/sys/amd64/include/param.h Thu, 02 Jul 2015 14:37:21 +0000 Konstantin Belousov <kib@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#64d6de26 Bump MAXCPU on amd64 from 64 to 256. In practice APIC only permits 255CPUs (IDs 0 through 254). Getting above that limit requires x2APIC.MFC after: 1 month List of files: /freebsd-14.2/sys/amd64/include/param.h Wed, 20 Aug 2014 16:06:24 +0000 John Baldwin <jhb@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#f3db4c53 Increase the TSS limit by one byte. The processor requires an additional bytewith all bits set to 1 beyond the I/O permission bitmap.Prior to this change accessing I/O ports [0xFFF8-0xFFFF] would trigger a#GP fault even though the I/O bitmap allowed access to those ports.For more details see section "I/O Permission Bit Map" in the Intel SDM, Vol 1.Reviewed by: kib List of files: /freebsd-14.2/sys/amd64/include/param.h Wed, 14 May 2014 22:24:09 +0000 Neel Natu <neel@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#941646f5 Rename VM_NDOMAIN into MAXMEMDOM and move it into machine/param.h inorder to match the MAXCPU concept. The change should also be usefulfor consolidation and consistency.Sponsored by: EMC / Isilon storage divisionObtained from: jeffReviewed by: alc List of files: /freebsd-14.2/sys/amd64/include/param.h Tue, 07 May 2013 22:46:24 +0000 Attilio Rao <attilio@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#e2082935 As discussed on -current, remove the hardcoded default maxswzone.MFC after: 3 weeks List of files: /freebsd-14.2/sys/amd64/include/param.h Tue, 14 Aug 2012 17:01:21 +0000 Dag-Erling Smørgrav <des@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#786ef92b Bump MAXCPU for amd64, ia64 and XLP mips appropriately.From now on, default values for FreeBSD will be 64 maxiumum supportedCPUs on amd64 and ia64 and 128 for XLP. All the other architecturesseem already capped appropriately (with the exception of sparc64 whichneeds further support on jalapeno flavour).Bump __FreeBSD_version in order to reflect KBI/KPI brekage introducedduring the infrastructure cleanup for supporting MAXCPU > 32. Thiscovers cpumask_t retiral too.The switch is considered completed at the present time, so for whateverbug you may experience that is reconducible to that area, please reportimmediately.Requested by: marcel, jchandraTested by: pluknet, sbrunoApproved by: re (kib) List of files: /freebsd-14.2/sys/amd64/include/param.h Tue, 19 Jul 2011 13:00:30 +0000 Attilio Rao <attilio@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#68b739cd Add the possibility to specify from kernel configs MAXCPU value.This patch is going to help in cases like mips flavours where youwant a more granular support on MAXCPU.No MFC is previewed for this patch.Tested by: pluknetApproved by: re (kib) List of files: /freebsd-14.2/sys/amd64/include/param.h Tue, 19 Jul 2011 00:37:24 +0000 Attilio Rao <attilio@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#74e4245e Bring back the number of CPU to 32. List of files: /freebsd-14.2/sys/amd64/include/param.h Tue, 07 Jun 2011 08:05:23 +0000 Attilio Rao <attilio@FreeBSD.org> http://172.16.0.5:8080/history/freebsd-14.2/sys/amd64/include/param.h#71a19bdc Commit the support for removing cpumask_t and replacing it directly withcpuset_t objects.That is going to offer the underlying support for a simple bump ofMAXCPU and then support for number of cpus > 32 (as it is today).Right now, cpumask_t is an int, 32 bits on all our supported architecture.cpumask_t on the other side is implemented as an array of longs, andeasilly extendible by definition.The architectures touched by this commit are the following:- amd64- i386- pc98- arm- ia64- XENwhile the others are still missing.Userland is believed to be fully converted with the changes containedhere.Some technical notes:- This commit may be considered an ABI nop for all the architectures different from amd64 and ia64 (and sparc64 in the future)- per-cpu members, which are now converted to cpuset_t, needs to be accessed avoiding migration, because the size of cpuset_t should be considered unknown- size of cpuset_t objects is different from kernel and userland (this is primirally done in order to leave some more space in userland to cope with KBI extensions). If you need to access kernel cpuset_t from the userland please refer to example in this patch on how to do that correctly (kgdb may be a good source, for example).- Support for other architectures is going to be added soon- Only MAXCPU for amd64 is bumped nowThe patch has been tested by sbruno and Nicholas Esborn on opteron4 x 12 pack CPUs. More testing on big SMP is expected to came soon.pluknet tested the patch with his 8-ways on both amd64 and i386.Tested by: pluknet, sbruno, gianni, Nicholas EsbornReviewed by: jeff, jhb, sbruno List of files: /freebsd-14.2/sys/amd64/include/param.h Thu, 05 May 2011 14:39:14 +0000 Attilio Rao <attilio@FreeBSD.org>