Summary:
POWER9 supports two MMU formats: traditional hashed page tables, and Radix
page tables, similar to what's presesnt on most other architectures. The
PowerISA also specifies a process table -- a table of page table pointers--
which on the POWER9 is only available with the Radix MMU, so we can take
advantage of it with the Radix MMU driver.
Written by Matt Macy.
Differential Revision: https://reviews.freebsd.org/D19516
This is a general cleanup of the relocatable kernel support on powerpc,
needed to enable kernel ifuncs.
* Fix some relocatable issues in the kernel linker, and change to using
a RELOCATABLE_KERNEL #define instead of #ifdef __powerpc__ for parts that
other platforms can use in the future if they wish to have ET_DYN kernels.
* Get rid of the DB_STOFFS hack now that the kernel is relocated to the DMAP
properly across the board on powerpc64.
* Add powerpc64 and powerpc32 ifunc functionality.
* Allow AIM64 virtual mode OF kernels to run from the DMAP like other AIM64
by implementing a virtual mode restart. This fixes the runtime address on
PowerMac G5.
* Fix symbol relocation problems on post-relocation kernels by relocating
the symbol table.
* Add an undocumented method for supplying kernel symbols on powernv and
other powerpc machines using linux-style kernel/initrd loading -- If
you pass the kernel in as the initrd as well, the copy resident in initrd
will be used as a source for symbols when initializing the debugger.
This method is subject to removal once we have a better way of doing this.
Approved by: jhibbits
Relnotes: yes
Sponsored by: Tag1 Consulting, Inc.
Differential Revision: https://reviews.freebsd.org/D23156
Save and restore (also known as suspend and resume) permits a snapshot
to be taken of a guest's state that can later be resumed. In the
current implementation, bhyve(8) creates a UNIX domain socket that is
used by bhyvectl(8) to send a request to save a snapshot (and
optionally exit after the snapshot has been taken). A snapshot
currently consists of two files: the first holds a copy of guest RAM,
and the second file holds other guest state such as vCPU register
values and device model state.
To resume a guest, bhyve(8) must be started with a matching pair of
command line arguments to instantiate the same set of device models as
well as a pointer to the saved snapshot.
While the current implementation is useful for several uses cases, it
has a few limitations. The file format for saving the guest state is
tied to the ABI of internal bhyve structures and is not
self-describing (in that it does not communicate the set of device
models present in the system). In addition, the state saved for some
device models closely matches the internal data structures which might
prove a challenge for compatibility of snapshot files across a range
of bhyve versions. The file format also does not currently support
versioning of individual chunks of state. As a result, the current
file format is not a fixed binary format and future revisions to save
and restore will break binary compatiblity of snapshot files. The
goal is to move to a more flexible format that adds versioning,
etc. and at that point to commit to providing a reasonable level of
compatibility. As a result, the current implementation is not enabled
by default. It can be enabled via the WITH_BHYVE_SNAPSHOT=yes option
for userland builds, and the kernel option BHYVE_SHAPSHOT.
Submitted by: Mihai Tiganus, Flavius Anton, Darius Mihai
Submitted by: Elena Mihailescu, Mihai Carabas, Sergiu Weisz
Relnotes: yes
Sponsored by: University Politehnica of Bucharest
Sponsored by: Matthew Grooms (student scholarships)
Sponsored by: iXsystems
Differential Revision: https://reviews.freebsd.org/D19495
Currently functionality resides in rtsock.c, which is a controlling
interface, partially external to the routing subsystem.
Additionally, DDB-supporting functionality is > 100SLOC, which deserves
a separate file.
Given that, move this functionality to a newly-created net/route/ subdir.
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D24561
Nexthop objects implementation, defined in r359823,
introduced sys/net/route directory intended to hold all
routing-related code. Move recently-introduced route_temporal.c and
private route_var.h header there.
Differential Revision: https://reviews.freebsd.org/D24597
Now that hw.machine_arch handles soft-float vs hard-float there is no
longer a reason for this config.
Submitted by: mhorne (kern.mk hunk)
Reviewed by: imp (earlier version), kp
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24544
Add driver for Broadcom "GENET" version 5, as found in BCM-2711 on
Raspberry Pi 4B. The driver is derived in part from the bcmgenet.c
driver in NetBSD, along with bcmgenetreg.h.
Reviewed by: manu
Obtained from: in part from NetBSD
Relnotes: yes, note addition
Differential Revision: https://reviews.freebsd.org/D24436
Replace our hand-rolled functions with the generic ones provided by
kern/subr_physmem.c. This greatly simplifies the initialization of
physical memory regions and kernel globals.
Tested by: nick
Differential Revision: https://reviews.freebsd.org/D24154
The arm_physmem interface found in arm's MD code provides a convenient
set of routines for adding/excluding physical memory regions and
initializing important kernel globals such as Maxmem, realmem,
phys_avail[], and dump_avail[]. It is especially convenient for FDT
systems, since we can use FDT parsing functions and pass the result
directly to one of these physmem routines. This interface is already in
use on arm and arm64, and can be used to simplify this early
initialization on RISC-V as well.
This requires only a couple trivial changes:
- Move arm_physmem_kernel_addr to arm/machdep.c. It is unused on arm64,
and manipulated entirely in arm MD code.
- Convert arm32_btop/arm64_btop to atop. This is equivalently defined
on all architectures.
- Drop the "arm" prefix.
Reviewed by: manu, emaste ("looks reasonable")
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D24153
Silence the "DWARF2 can only represent one section per compilation unit"
warning in amd64 GENERIC builds by disabling Clang's debuginfo generation for
this assembler file (-g0). The message is replaced by a warning from
ctfconvert that there is no debuginfo to convert (future work).
The file contains some metadata (several ELF notes) and some code. The code
does not appear to have anything that debuginfo would aid.
I looked at the generated debuginfo (readelf -w xen-locore.o) prior to this
change, and the metadata that would be disabled are things like associated
between binary offset and code line number (not especially useful with a
disassembler), and label metadata for the entry points (not especially useful
as this is already in the symbol table).
Reviewed by: royger
Differential Revision: https://reviews.freebsd.org/D24384
It is not logically dependent on "device mem", and an arm kernel
compiled without that device fails to link since the minidumpsys()
symbol is referenced by kern_dump.c.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
the dts to find the supported speeds and the regulators.
Not all DTS have every settings properly defined so host controller
will still have to add some caps themselves.
It also add a mmc_fdt_gpio_setup function which will read the cd-gpios
property and register it as the CD pin.
If the pin support interrupts one will be registered and the cd_helper
function will be called.
If the pin doesn't support interrupts the internal taskqueue will poll
for change and call the same cd_helper function.
mmc_fdt_gpio_setup will also parse the wp-gpio property and MMC drivers
can know the write-protect pin value by calling the
mmc_fdt_gpio_get_readonly function.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D23267
The file handle affinity code was configured to be used by both the
old and new NFS servers. This no longer makes sense, since there is
only one NFS server.
This patch copies a majority of the code in sys/nfs/nfs_fha.c and
sys/nfs/nfs_fha.h into sys/fs/nfsserver/nfs_fha_new.c and
sys/fs/nfsserver/nfs_fha_new.h, so that the files in sys/nfs can be
deleted. The code is simplified by deleting the function callback pointers
used to call functions in either the old or new NFS server and they were
replaced by calls to the functions.
As well as a cleanup, this re-organization simplifies the changes
required for handling of external page mbufs, which is required for KERN_TLS.
This patch should not result in a semantic change to file handle affinity.
It changes the size of TAILQ_ENTRY, which obviously impacts ABI in a variety of
ways. Some of these things are _Static_asserted. For now, mask the option
from LINT.
Reported by: crees, np, jhb
X-MFC-With: r359829
Sponsored by: Dell EMC Isilon
Add QUEUE_MACRO_DEBUG_TRACE and QUEUE_MACRO_DEBUG_TRASH as proper kernel
options. While here, alpha-sort the debug section of sys/conf/options.
Enable QUEUE_MACRO_DEBUG_TRASH in amd64 GENERIC (but not GENERIC-NODEBUG)
kernels. It is similar in nature and cost to other use-after-free pointer
trashing we do in GENERIC. It is probably reasonable to enable in any arch
GENERIC kernel that defines INVARIANTS.
This is the foundational change for the routing subsytem rearchitecture.
More details and goals are available in https://reviews.freebsd.org/D24141 .
This patch introduces concept of nexthop objects and new nexthop-based
routing KPI.
Nexthops are objects, containing all necessary information for performing
the packet output decision. Output interface, mtu, flags, gw address goes
there. For most of the cases, these objects will serve the same role as
the struct rtentry is currently serving.
Typically there will be low tens of such objects for the router even with
multiple BGP full-views, as these objects will be shared between routing
entries. This allows to store more information in the nexthop.
New KPI:
struct nhop_object *fib4_lookup(uint32_t fibnum, struct in_addr dst,
uint32_t scopeid, uint32_t flags, uint32_t flowid);
struct nhop_object *fib6_lookup(uint32_t fibnum, const struct in6_addr *dst6,
uint32_t scopeid, uint32_t flags, uint32_t flowid);
These 2 function are intended to replace all all flavours of
<in_|in6_>rtalloc[1]<_ign><_fib>, mpath functions and the previous
fib[46]-generation functions.
Upon successful lookup, they return nexthop object which is guaranteed to
exist within current NET_EPOCH. If longer lifetime is desired, one can
specify NHR_REF as a flag and get a referenced version of the nexthop.
Reference semantic closely resembles rtentry one, allowing sed-style conversion.
Additionally, another 2 functions are introduced to support uRPF functionality
inside variety of our firewalls. Their primary goal is to hide the multipath
implementation details inside the routing subsystem, greatly simplifying
firewalls implementation:
int fib4_lookup_urpf(uint32_t fibnum, struct in_addr dst, uint32_t scopeid,
uint32_t flags, const struct ifnet *src_if);
int fib6_lookup_urpf(uint32_t fibnum, const struct in6_addr *dst6, uint32_t scopeid,
uint32_t flags, const struct ifnet *src_if);
All functions have a separate scopeid argument, paving way to eliminating IPv6 scope
embedding and allowing to support IPv4 link-locals in the future.
Structure changes:
* rtentry gets new 'rt_nhop' pointer, slightly growing the overall size.
* rib_head gets new 'rnh_preadd' callback pointer, slightly growing overall sz.
Old KPI:
During the transition state old and new KPI will coexists. As there are another 4-5
decent-sized conversion patches, it will probably take a couple of weeks.
To support both KPIs, fields not required by the new KPI (most of rtentry) has to be
kept, resulting in the temporary size increase.
Once conversion is finished, rtentry will notably shrink.
More details:
* architectural overview: https://reviews.freebsd.org/D24141
* list of the next changes: https://reviews.freebsd.org/D24232
Reviewed by: ae,glebius(initial version)
Differential Revision: https://reviews.freebsd.org/D24232
This removes support for using DES, Triple DES, and RC4.
Reviewed by: cem, kp
Tested by: kp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D24344
This NFS lock device driver was replaced by the kernel NLM around FreeBSD7 and
has not normally been used since then.
To use it, the kernel had to be built without "options NFSLOCKD" and
the nfslockd.ko had to be deleted as well.
Since it uses Giant and is no longer used, this patch removes it.
With this device driver removed, there is now a lot of unused code
in the userland rpc.lockd. That will be removed on a future commit.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D22933
-fno-common will become the default in GCC10/LLVM11. Plenty of work has been
put in to make sure our world builds are no -fno-common clean, so let's slap
the build with this until it becomes the compiler default to ensure we don't
regress.
At this time, we will not be enforcing -fno-common on ports builds. I
suspect most ports will be or quickly become -fno-common clean as they're
naturally built against compilers that default to it, so this will hopefully
become a non-issue in due time. The exception to this, which is actually the
status quo, is that kmods built from ports will continue to build with
-fno-common.
As of the time of writing, I intend to also make stable/12 -fno-common
clean. What's been done will be MFC'd to stable/11 if it's easily applicable
and/or not much work to massage it into being functional, but I anticipate
adding -fcommon to stable/11 builds to maintain its ability to be built with
newer compilers for the rest of its lifetime instead of putting in a third
branch's worth of effort.
The mechanism that generates assym.inc and offset.inc depends on the
symbols in question being common. For now, simply force the object files
to be created with -fcommon.
-fno-common will be the default in GCC10/LLVM11.
Submitted by: arichardson
Reviewed by: kevans
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24322
Like the X5000, the main CPLD on the A1222 is the communication medium
between the CPU and the GPIO CPLD. It provides a mailbox communication
feature, along with dual-port RAM accessible from both the CPU and GPIO
CPLD, and 3 fan speed reporting registers.
Modern debuggers and process tracers use ptrace() rather than procfs
for debugging. ptrace() has a supserset of functionality available
via procfs and new debugging features are only added to ptrace().
While the two debugging services share some fields in struct proc,
they each use dedicated fields and separate code. This results in
extra complexity to support a feature that hasn't been enabled in the
default install for several years.
PR: 244939 (exp-run)
Reviewed by: kib, mjg (earlier version)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D23837
It appears that the macOS /bin/sh echo now defaults to -e and therefore the
`#define VERSTR` included newline characters instead of \n. This caused compiler
errors due to unterminated strings. Fix by using printf instead of echo.
A less fragile solution might be to bootstrap the in-tree /bin/sh but that
requires more changes.
Reviewed By: brooks
Differential Revision: https://reviews.freebsd.org/D24136
LLD complains that the type of .dynamic was changed. Fix this by copying
the approach used in the mips64 ldscript.
I do not have hardware to test this change so I only verified that the
kernel links and the section layout looks sensible.
Reviewed By: imp, emaste
Differential Revision: https://reviews.freebsd.org/D24093
Centralize the list of generated files required by linuxkpi consumers,
into the common variable. This way, consumers that use the variable
are insulated from possible changes in the list.
Reviewed by: hselasky, imp
Sponsored by: Mellanox Technologies
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D24137
The devices supported by these drivers are obsolete ISA cards, and the
sync serial protocols they supported are essentially obsolete too.
Sponsored by: The FreeBSD Foundation
Summary:
The support was added almost a decade ago, and never completed. Just axe
it. It was also inadvertently broken 5 years ago, and nobody noticed.
Reviewed by: bdragon
Differential Revision: https://reviews.freebsd.org/D23753
The ixl driver now works on PowerPC64 and may be compiled in-kernel and
as a module.
Reviewed by: alfredo, erj
Sponsored by: Eldorado Research Institute (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D23974
When iicbus is attached as child of Designware I2C controller it scans all
ACPI nodes for "I2C Serial Bus Connection Resource Descriptor" described
in section 19.6.57 of ACPI specs.
If such a descriptor is found, I2C child is added to iicbus, it's I2C
address, IRQ resource and ACPI handle are added to ivars. Existing
ACPI bus-hosted child is deleted afterwards.
The driver also installs so called "I2C address space handler" which is
disabled by default as nontested.
Set hw.iicbus.enable_acpi_space_handler loader tunable to 1 to enable it.
Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D22901
file systems to safely access their disk devices, and adapt FFS to use it.
Also add a new BO_NOBUFS flag to allow enforcing that file systems using
mntfs vnodes do not accidentally use the original devfs vnode to create buffers.
Reviewed by: kib, mckusick
Approved by: imp (mentor)
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D23787
Port aacraid driver to big-endian (BE) hosts.
The immediate goal of this change is to make it possible to use the
aacraid driver on PowerPC64 machines that have Adaptec Series 8 SAS
controllers.
Adapters supported by this driver expect FIB contents in little-endian
(LE) byte order. All FIBs have a fixed header part as well as a data
part that depends on the command being issued to the controller.
In this way, on BE hosts, the FIB header and all FIB data structures
used in aacraid.c and aacraid_cam.c need to be converted to LE before
being sent to the adapter and converted to BE when coming from it.
The functions to convert each struct are on aacraid_endian.c.
For little-endian (LE) targets, they are macros that expand
to nothing.
In some cases, when only a few fields of a large structure are used,
the fields are converted inline, by the code using them.
PR: 237463
Reviewed by: jhibbits
Sponsored by: Eldorado Research Institute (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D23887
Use __riscv_flen instead of __riscv_float_abi_soft. While the latter works for
userland (and one could argue it's more correct), it fails for the kernel. We
compile the kernel with -mabi=lp64 (eg soft float abi) to avoid floating point
instructions in the kernel. We also compile the kernel -march=rv64imafdc for
hard float kernels (eg those with options FPE), but with -march=rv64imac for
softfloat kernels (eg those with FPE). Since we do this, in the kernel (as in
userland) __riscv_flen will be defined for 'riscv64' and not for 'riscv64sf'.
This also removes the -DMACHINE_ARCH hack now that it's no longer needed.
Longer term, we should return the ABI from the sysctl hw.machine_arch like on
amd64 for i386 binaries.
Suggested by: mhorne@
Differential Revision: https://reviews.freebsd.org/D23813
GENERICSF is just like GENERIC, only creates a soft-float kernel. Omit it from the
universe build for now.
Reviewed by: philip
Differential Revision: https://reviews.freebsd.org/D23812
TARGET_ARCH is only for use in Makefile.inc1 contexts. MACHINE_ARCH is the
preferred thing to set. Makefile.inc1 sets MACHINE_ARCH in the cross build
case, and make sets it in the native build case. This will fix anybody doing a
native build. Add a comment for why we have to do this dance so when/if the
problem with CFLAGS is fixed for the kernel this workaround can be removed.
MACHINE_ARCH sets the hw.machine_arch sysctl in the kernel. In userspace
it sets MACHINE_ARCH in bmake, which bsd.cpu.mk uses to configure the
target ABI for ports.
For riscv64sf builds (i.e. soft-float) that needs to be riscv64sf, but
the sysctl didn't reflect that. It is static.
Set the define from the riscv makefile so that we correctly reflect our
actual build (i.e. riscv64 or riscv64sf), depending on what TARGET_ARCH
we were built with.
That still doesn't satisfy userspace builds (e.g. bmake), so check if
we're building with a software-floating point toolchain there. That
check doesn't work in the kernel, because it never uses floating point.
Reviewed by: philip (previous version), mhorne
Sponsored by: Axiado
Differential Revision: https://reviews.freebsd.org/D23741
For drmkpi (D23085) we don't want the Linux struct file as we don't emulate
everything. Also the prototypes should be in shmem_fs.h to have 100%
compatibility with Linux.
Reviewed by: hselasky
MFC after: Maybe
Differential Revision: https://reviews.freebsd.org/D23764
Platform (N1SDP).
Neoverse N1 is a high-performance ARM microarchitecture designed
by the ARM Holdings for the server market.
The PCI part on N1SDP was shipped untested and suffers from some
integration issues.
For instance accessing to not existing BDFs causes System Error
(SError) exception. To mitigate this, the firmware scans the bus,
catches SErrors and creates a table with valid BDFs. That allows
us to filter-out accesses to invalid BDFs in this driver.
Also the root complex config space (BDF == 0) has an unusual
location in memory map, so remapping accesses to it is required.
Finally, the config space is restricted to 32-bit accesses only.
This was tested on the ARM boxes kindly provided by the ARM Ltd
to the DARPA CHERI Project.
In collaboration with: andrew
Reviewed by: andrew
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D23349
This allows us to boot FreeBSD RISCV on QEMU using the -kernel command line
options. When using that option, QEMU maps the kernel ELF file to the
addresses specified in the LMAs in the program headers.
Since version 4.2 QEMU ships with OpenSBI fw_jump by default so this allows
booting FreeBSD using the following command line:
qemu-system-riscv64 -bios default -kernel /.../boot/kernel/kernel -nographic -M virt
Without this change the -kernel option cannot be used since the LMAs start
at address zero and QEMU already maps a ROM to these low physical addresses.
For targets that require a different kernel LMA the make variable
KERNEL_LMA can be overwritten in the config file. For example, adding
`makeoptions KERNEL_LMA=0xc0200000` will create an ELF file that will be
loaded at 0xc0200000.
Before:
There are 4 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x001000 0xffffffc000000000 0x0000000000000000 0x75e598 0x8be318 RWE 0x1000
DYNAMIC 0x71fb20 0xffffffc00071eb20 0x000000000071eb20 0x000100 0x000100 RW 0x8
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x0
NOTE 0x693400 0xffffffc000692400 0x0000000000692400 0x000024 0x000024 R 0x4
After:
There are 4 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x001000 0xffffffc000000000 0x0000000080200000 0x734198 0x893e18 RWE 0x1000
DYNAMIC 0x6f7810 0xffffffc0006f6810 0x00000000808f6810 0x000100 0x000100 RW 0x8
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x0
NOTE 0x66ca70 0xffffffc00066ba70 0x000000008086ba70 0x000024 0x000024 R 0x4
Reviewed By: br, mhorne (earlier version)
Differential Revision: https://reviews.freebsd.org/D23436
Once all CPUs are online, determine if they all support LSE atomics and
set lse_supported to indicate this. For now the atomic(9)
implementations are still always inlined, though it would be preferable
to create out-of-line functions to avoid text bloat. This was not done
here since big.little systems exist in which some CPUs implement LSE
while others do not, and ifunc resolution must occur well before this
scenario can be detected. It does seem unlikely that FreeBSD will
ever run on such platforms, however, so converting atomic(9) to use
ifuncs is probably a good next step.
Add a LSE_ATOMICS arm64 kernel configuration option to unconditionally
select LSE-based atomic(9) implementations when the target system is
known.
Reviewed by: andrew, kib
MFC after: 1 month
Sponsored by: The FreeBSD Foundation, Amazon (hardware)
Differential Revision: https://reviews.freebsd.org/D23325
fonts. As a workaround, remove the static. vt is default on powerpc, but there's
a few old macs that still fail with vt. sc is used as a work arouond for those
machines, and the kernel fails to build w/o it.
Use ${SRCTOP} instead of /usr/share.
Prefer to depend on option sc_dflt_fnt instead of sc.
gc the 4 otherwise identical instances in the tree.
Platforms that don't need this won't included it.
Fix the old-style build by using ${SRCTOP} instead of a weird
construct that only works for new-style build.
Simplify the building of keymap files by using macros
Move atkbdmap.h in files.x86
This has been broken since r296899 which removed the implicit
dependency on /usr/share.
Now that armv5 is gone, we no longer need multiple LINT files. Kill
the odd-ball support here. From now on, we just have LINT built from
notes like all the other platforms. Keep the removal of LINT-V5/7
to remove stale files for a while still..
The Parallel Port SCSI adapter was interesting for 100MB ZIP drives, but is no
longer used or maintained. Remove it from the tree.
The Parallel Port microsequencer (microseq.9) is now mostly unused in the tree,
but remains. PPI still refrences it, but doesn't use its full functionality.
Relnotes: Yes
Reviewed by: rgrimes@, Ihor Antonov
Discussed on: arch@
Differential Revision: https://reviews.freebsd.org/D23389
the ! operator should have been a ~ instead:
Merge r357348 from the clang 10.0.0 import branch:
Disable new clang 10.0.0 warnings about converting the result of
shift operations to a boolean in tpm(4):
sys/dev/tpm/tpm_crb.c:301:32: error: converting the result of '<<' to a boolean; did you mean '(1 << (0)) != 0'? [-Werror,-Wint-in-bool-context]
WR4(sc, TPM_CRB_CTRL_CANCEL, !TPM_CRB_CTRL_CANCEL_CMD);
^
sys/dev/tpm/tpm_crb.c:73:34: note: expanded from macro 'TPM_CRB_CTRL_CANCEL_CMD'
#define TPM_CRB_CTRL_CANCEL_CMD BIT(0)
^
sys/dev/tpm/tpm20.h:60:19: note: expanded from macro 'BIT'
#define BIT(x) (1 << (x))
^
Such warnings can be useful in C++ contexts, but not so much in kernel
drivers, where this type of bit twiddling is commonplace. So disable
it for this case.
Noticed by: cem
MFC after: 3 days
Disable new clang 10.0.0 warnings about converting the result of shift
operations to a boolean in tpm(4):
sys/dev/tpm/tpm_crb.c:301:32: error: converting the result of '<<' to a boolean; did you mean '(1 << (0)) != 0'? [-Werror,-Wint-in-bool-context]
WR4(sc, TPM_CRB_CTRL_CANCEL, !TPM_CRB_CTRL_CANCEL_CMD);
^
sys/dev/tpm/tpm_crb.c:73:34: note: expanded from macro 'TPM_CRB_CTRL_CANCEL_CMD'
#define TPM_CRB_CTRL_CANCEL_CMD BIT(0)
^
sys/dev/tpm/tpm20.h:60:19: note: expanded from macro 'BIT'
#define BIT(x) (1 << (x))
^
Such warnings can be useful in C++ contexts, but not so much in kernel
drivers, where this type of bit twiddling is commonplace. So disable it
for this case.
MFC after: 3 days
operations to a boolean in tpm(4):
sys/dev/tpm/tpm_crb.c:301:32: error: converting the result of '<<' to a boolean; did you mean '(1 << (0)) != 0'? [-Werror,-Wint-in-bool-context]
WR4(sc, TPM_CRB_CTRL_CANCEL, !TPM_CRB_CTRL_CANCEL_CMD);
^
sys/dev/tpm/tpm_crb.c:73:34: note: expanded from macro 'TPM_CRB_CTRL_CANCEL_CMD'
#define TPM_CRB_CTRL_CANCEL_CMD BIT(0)
^
sys/dev/tpm/tpm20.h:60:19: note: expanded from macro 'BIT'
#define BIT(x) (1 << (x))
^
Such warnings can be useful in C++ contexts, but not so much in kernel
drivers, where this type of bit twiddling is commonplace. So disable it
for this case.
MFC after: 3 days
This is in the same family of algorithms as Epoch/QSBR/RCU/PARSEC but is
a unique algorithm. This has 3x the performance of epoch in a write heavy
workload with less than half of the read side cost. The memory overhead
is significantly lessened by limiting the free-to-use latency. A synthetic
test uses 1/20th of the memory vs Epoch. There is significant further
discussion in the comments and code review.
This code should be considered experimental. I will write a man page after
it has settled. After further validation the VM will begin using this
feature to permit lockless page lookups.
Both markj and cperciva tested on arm64 at large core counts to verify
fences on weaker ordering architectures. I will commit a stress testing
tool in a follow-up.
Reviewed by: mmacy, markj, rlibby, hselasky
Discussed with: sbahara
Differential Revision: https://reviews.freebsd.org/D22586
MAC is also almost universally a default; every GENERIC includes it, and
it's std.armv[67]. mips is again the oddball here with it only being
included in ERL/OCTEON1.
The only module currently working around this one is mac_veriexec, but it
looks like nothing it builds actually uses the MAC definition. Downstream
consumers enabling MAC in mips using mac_veriexec may be advised to do
something differently here in config.mk.
For untied module builds, we'll generate opt_foo headers if they're included
in SRCS. However, options that would normally be represented in opt_global.h
aren't properly represented.
Start generating opt_global.h with #define VIMAGE for !mips since it's
almost universally a project default and right now kmods must hack it in
themselves in order to be properly compiled for the default kernel. For
example, ^/sys/modules/pf/Makefile
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D23345
Originally, hack.c was compiled into a shard object with just -shared
-nostdlib. This assumed that ${CC} did not require any additional
flags for ABIs, cross-building, etc.
When kern.post.mk was created in r89509 by reducing duplication in
kernel Makefile.<arch> files, the -shared flag was moved into a
HACK_EXTRA_FLAGS variable so that sparc64 could override it with
-Wl,-shared. The sparc64 hack was removed in r111650, but
HACK_EXTRA_FLAGS was left in place. Over time, we have started
support toolchains that require flags to support alternate ABIs on
MIPS and PowerPC and started (ab)using HACK_EXTRA_FLAGS to set only
those flags.
I need to fix risc-v to pass -mno-relax to the hack.c build for lld in
llvm 10, and the patches to support cross-build from non-FreeBSD hosts
need to include -target for clang in CFLAGS for hack.c. Rather than
adding more hacks into HACK_EXTRA_FLAGS, just use the full set of
CFLAGS with hack.c.
Reviewed by: kib, arichardson
MFC after: 1 month
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D23362
Intel Speed Shift is Intel's technology to control frequency in hardware,
with hints from software.
Let's get a working version of this in the tree and we can refine it from
here.
Submitted by: bwidawsk, scottph
Reviewed by: bcr (manpages), myself
Discussed with: jhb, kib (earlier versions)
With feedback from: Greg V, gallatin, freebsdnewbie AT freenet.de
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D18028
Redirect (and temporal) route expiration was broken a while ago.
This change brings route expiration back, with unified IPv4/IPv6 handling code.
It introduces net.inet.icmp.redirtimeout sysctl, allowing to set
an expiration time for redirected routes. It defaults to 10 minutes,
analogues with net.inet6.icmp6.redirtimeout.
Implementation uses separate file, route_temporal.c, as route.c is already
bloated with tons of different functions.
Internally, expiration is implemented as an per-rnh callout scheduled when
route with non-zero rt_expire time is added or rt_expire is changed.
It does not add any overhead when no temporal routes are present.
Callout traverses entire routing tree under wlock, scheduling expired routes
for deletion and calculating the next time it needs to be run. The rationale
for such implemention is the following: typically workloads requiring large
amount of routes have redirects turned off already, while the systems with
small amount of routes will not inhibit large overhead during tree traversal.
This changes also fixes netstat -rn display of route expiration time, which
has been broken since the conversion from kread() to sysctl.
Reviewed by: bz
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D23075
The main objective here is to make it easy to identify what needs to change
in order to use a different sysent generator than the current Lua-based one,
which may be used to MFC some of the changes that have happened so we can
avoid parallel accidents in stable branches, for instance.
As a secondary objective, it's now feasible to override the generator on a
per-Makefile basis if needed, so that one could refactor their Makefile to
use this while pinning generation to the legacy makesyscalls.sh. I don't
anticipate any consistent need for such a thing, but it's low-effort to
achieve.
Summary:
The CPLD is the communications medium between the CPU and the XMOS
"Xena" event coprocessor. It provides a mailbox communication feature,
along with dual-port RAM to be used between the CPU and XMOS. Also, it
provides basic board stats as well, such as PCIe presence, JTAG signals,
and CPU fan speed reporting (in revolutions per second). Only fan speed
reading is handled, as a sysctl.
Reviewed by: bdragon
Differential Revision: https://reviews.freebsd.org/D23136
r355473 vastly improved the readability and cleanliness of these Makefiles.
Every single one of them follows the same pattern and duplicates the exact
same logic.
Now that we have GENERATED/SRCS, split SRCS up into the two parameters we'll
use for ${MAKESYSCALLS} rather than assuming a specific ordering of SRCS and
include a common sysent.mk to handle the rest. This makes it less tedious to
make sweeping changes.
Some default values are provided for GENERATED/SYSENT_*; almost all of these
just use a 'syscalls.master' and 'syscalls.conf' in cwd, and they all use
effectively the same filenames with an arbitrary prefix. Most ABIs will be
able to get away with just setting GENERATED_PREFIX and including
^/sys/conf/sysent.mk, while others only need light additions. kern/Makefile
is the notable exception, as it doesn't take a SYSENT_CONF and the generated
files are spread out between ^/sys/kern and ^/sys/sys, but it otherwise fits
the pattern enough to use the common version.
Reviewed by: brooks, imp
Nice!: emaste
Differential Revision: https://reviews.freebsd.org/D23197
The utility here seems somewhat limited, but clang will attempt to generate
.eh_frame and actively fail in doing so. It is perhaps worth investigating
why it's being generated in the first place (GCC doesn't do so), but this
isn't a high priority.
lld on RISC-V is not yet able to handle undefined weak symbols for
non-PIC code in the code model (medany/medium) used by the RISC-V
kernel.
Both GCC and clang emit an auipc / addi pair of instructions to
generate an address relative to the current PC with a 31-bit offset.
Undefined weak symbols need to have an address of 0, but the kernel
runs with PC values much greater than 2^31, so there is no way to
construct a NULL pointer as a PC-relative value. The bfd linker
rewrites the instruction pair to use lui / addi with values of 0 to
force a NULL pointer address. (There are similar cases for 'ld'
becoming auipc / ld that bfd rewrites to lui / ld with an address of
0.)
To work around this, compile the kernel with -fPIE when using lld.
This does not make the kernel position-independent, but it does
force the compiler to indirect address lookups through GOT entries
(so auipc / ld against a GOT entry to fetch the address). This
adds extra memory indirections for global symbols, so should be
disabled once lld is finally fixed.
A few 'la' instructions in locore that depend on PC-relative
addressing to load physical addresses before paging is enabled have to
use auipc / addi and not indirect via GOT entries, so change those to
use 'lla' which always uses auipc / addi for both PIC and non-PIC.
Submitted by: jrtc27
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D23064
more consistent with other NUMA features as UMA_ZONE_FIRSTTOUCH and
UMA_ZONE_ROUNDROBIN. The system will now pick a select a default depending
on kernel configuration. API users need only specify one if they want to
override the default.
Remove the UMA_XDOMAIN and UMA_FIRSTTOUCH kernel options and key only off
of NUMA. XDOMAIN is now fast enough in all cases to enable whenever NUMA
is.
Reviewed by: markj
Discussed with: rlibby
Differential Revision: https://reviews.freebsd.org/D22831
This is a lock-based emulation of 64-bit atomics for kernel use, split off
from an earlier patch by jhibbits.
This is needed to unblock future improvements that reduce the need for
locking on 64-bit platforms by using atomic updates.
The implementation allows for future integration with userland atomic64,
but as that implies going through sysarch for every use, the current
status quo of userland doing its own locking may be for the best.
Submitted by: jhibbits (original patch), kevans (mips bits)
Reviewed by: jhibbits, jeff, kevans
Differential Revision: https://reviews.freebsd.org/D22976
The fdt attachment for this heavily relies on extres for clk work. This
unbreaks the build for mips XLPN32/XLP, which have pci/fdt but no need for
this fdt attachment.
An i2c bus can be divided into segments which can be selectively connected
and disconnected from the main bus. This is usually done to enable using
multiple slave devices having the same address, by isolating the devices
onto separate bus segments, only one of which is connected to the main bus
at once.
There are several types of i2c bus muxes, which break down into two general
categories...
- Muxes which are themselves i2c slaves. These devices respond to i2c
commands on their upstream bus, and based on those commands, connect
various downstream buses to the upstream. In newbus terms, they are both
a child of an iicbus and the parent of one or more iicbus instances.
- Muxes which are not i2c devices themselves. Such devices are part of the
i2c bus electrically, but in newbus terms their parent is some other
bus. The association with the upstream bus must be established by
separate metadata (such as FDT data).
In both cases, the mux driver has one or more iicbus child instances
representing the downstream buses. The mux driver implements the iicbus_if
interface, as if it were an iichb host bridge/i2c controller driver. It
services the IO requests sent to it by forwarding them to the iicbus
instance representing the upstream bus, after electrically connecting the
upstream bus to the downstream bus that hosts the i2c slave device which
made the IO request.
The net effect is automatic mux switching which is transparent to slaves on
the downstream buses. They just do i2c IO they way they normally do, and the
bus is electrically connected for the duration of the IO and then idled when
it is complete.
The existing iicbus_if callback() method is enhanced so that the parameter
passed to it can be a struct which contains a device_t for the requesting
bus and slave devices. This change is done by adding a flag that indicates
the extra values are present, and making the flags field the first field of
a new args struct. If the flag is set, the iichb or mux driver can recast
the pointer-to-flags into a pointer-to-struct and access the extra
fields. Thus abi compatibility with older drivers is retained (but a mux
cannot exist on the bus with the older iicbus driver in use.)
A new set of core support routines exists in iicbus.c. This code will help
implement mux drivers for any type of mux hardware by supplying all the
boilerplate code that forwards IO requests upstream. It also has code for
parsing metadata and instantiating the child iicbus instances based on it.
Two new hardware mux drivers are added. The ltc430x driver supports the
LTC4305/4306 mux chips which are controlled via i2c commands. The
iic_gpiomux driver supports any mux hardware which is controlled by
manipulating the state of one or more gpio pins. Test Plan
Tested locally using a variety of mux'd bus configurations involving both
ltc4305 and a homebrew gpio-controlled mux. Tested configurations included
cascaded muxes (unlikely in the real world, but useful to prove that 'it all
just works' in terms of the automatic switching and upstream forwarding of
IO requests).
This brings arm into line with how every other arch does it. For some
reason, only arm lacked a definition of a symbol named kernbase in its
locore.S file(s) for use in its ldscript.arm file. Needlessly different
means harder to maintain.
Using a common symbol name also eases work in progress on a script to help
generate arm and arm64 kernels packaged in various ways (like with a header
blob needed for a bootloader prepended to the kernel file).
symbols from the linked kernel.
The main thrust of this change is to generate a kernel that has the arm
"marker" symbols stripped. Marker symbols start with $a, $d, $t or $x, and
are emitted by the compiler to tell other toolchain components about the
locations of data embedded in the instruction stream (literal-pool
stuff). They are used for generating mixed-endian binaries (which we don't
support). The linked kernel has approximately 21,000 such symbols in it,
wasting space (500K in kernel.full, 190K in the final linked kernel), and
sometimes obscuring function names in stack tracebacks.
This change also simplifies the way the kernel is linked. Instead of using
sed to generate two different ldscript files to generate both an elf kernel
and a binary (elf headers stripped) kernel, we now use a single ldscript
that refers to a "text_start" symbol, and we provide the value for that
symbol using --defsym on the linker command line.
This driver configure the registers in the GRF according to the value
of the regulators for the platform.
Some IP can run with either 3.0V or 1.8V, if we don't configure them
correctly according to the external voltage used they will not work.
It's only done at boot time for now and might be needed at runtime for
IP like sdmmc.
Reviewed by: mmel
Tested On: RockPro64, Firefly-RK3399 (gonzo), AIO-3288 (mmel)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D22854
* Fix a couple of format errors.
* Add some extra compiler flags needed to force clang to build SPE code.
(These are temporary until the target triple is fixed)
To improve reliability of kernel modules after the clang switch, switch to
-fPIC when building for now.
This bypasses some limitations to the way clang and LLD handle relocations,
and is a more robustly tested compilation regime than the
"static shared object" mode that we were previously attempting to convince
the compiler stack to use.
The kernel linker was recently augmented to be able to handle this mode.
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D22798
other files.
Arm and mips systems need to replace the SYSTEM_LD variable because they
need to create intermediate files which are post-processed with objcopy to
create the final .TARGET file. Previously they did so by pasting the full
expansion of SYSTEM_LD with the output filename replaced. This means
changing SYSTEM_LD in kern.pre.mk means you need to chase down anything that
replaces it and figure out how it differs so you can paste your changes in
there too.
Now there is a SYSTEM_LD_BASECMD variable that holds the entire basic kernel
linker command without the input and output files. This will allow arm and
mips makefiles to create their custom versions by refering to
SYSTEM_LD_BASECMD, which then becomes the one place where you have to make
changes to the basic linker command args.
Differential Revision: https://reviews.freebsd.org/D22921
SYSTEM_LD variable. This avoids duplicating the contents of SYSTEM_LD
from kern.pre.mk just to add the -N flag to it. If the basic linker command
ever needs to be changed, this will be one less place that has to be found
and fixed.
Some testing by kp@ indicates that the -N flag may not be needed at all,
so a comment to that effect is also added, and the -N flag may be removed
in a followup commit.
Differential Revision: https://reviews.freebsd.org/D22920
The VM generation counter is a 128-bit value exposed by the BIOS via ACPI.
The value changes to another unique identifier whenever a VM is duplicated.
Additionally, ACPI provides notification events when such events occur.
The driver decodes the pointer to the UUID, exports the value to userspace
via OPAQUE sysctl blob, and forwards the ACPI notifications in the form of
an EVENTHANDLER invocation as well as userspace devctl events.
See design paper: https://go.microsoft.com/fwlink/p/?LinkID=260709
This is lame, but it's what we already do for the clang build. We take
misaligned pointers into network header structures in many places.
Reviewed by: ian
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D22876
The OpenCores I2C IP core can be found on any bus. Split out the PCI
bus specifics into their own file, only compiled on systems with PCI.
Reviewed by: kp
Sponsored by: Axiado
