hardenedbsd/HardenedBSD
1
0
Fork 0
mirror of https://git.hardenedbsd.org/hardenedbsd/HardenedBSD.git synced 2024-11-15 14:56:13 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity
cbf65cf228
HardenedBSD/sys/conf/files.amd64

757 lines
33 KiB
Plaintext
Raw Normal View History

This is the start of the FreeBSD/x86_64 kernel.
2002-06-30 10:05:21 +02:00
# This file tells config what files go into building a kernel,
# files marked standard are always included.
#
# $FreeBSD$
#
# The long compile-with and dependency lines are required because of
# limitations in config: backslash-newline doesn't work in strings, and
# dependency lines other than the first are silently ignored.
#
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 09:55:06 +02:00
#
Make execution of 32-bit CloudABI executables work on amd64. A nice thing about requiring a vDSO is that it makes it incredibly easy to provide full support for running 32-bit processes on 64-bit systems. Instead of letting the kernel be responsible for composing/decomposing 64-bit arguments across multiple registers/stack slots, all of this can now be done in the vDSO. This means that there is no need to provide duplicate copies of certain system calls, like the sys_lseek() and freebsd32_lseek() we have for COMPAT_FREEBSD32. This change imports a new vDSO from the CloudABI repository that has automatically generated code in it that copies system call arguments into a buffer, padding them to eight bytes and zero-extending any pointers/size_t arguments. After returning from the kernel, it does the inverse: extracting return values, in the process truncating pointers/size_t values to 32 bits. Obtained from: https://github.com/NuxiNL/cloudabi
2016-08-24 12:51:33 +02:00
cloudabi32_vdso.o optional compat_cloudabi32 \
dependency "$S/contrib/cloudabi/cloudabi_vdso_i686_on_64bit.S" \
compile-with "${CC} -x assembler-with-cpp -m32 -shared -nostdinc -nostdlib -Wl,-T$S/compat/cloudabi/cloudabi_vdso.lds $S/contrib/cloudabi/cloudabi_vdso_i686_on_64bit.S -o ${.TARGET}" \
no-obj no-implicit-rule \
clean "cloudabi32_vdso.o"
#
cloudabi32_vdso_blob.o optional compat_cloudabi32 \
dependency "cloudabi32_vdso.o" \
compile-with "${OBJCOPY} --input-target binary --output-target elf64-x86-64-freebsd --binary-architecture i386 cloudabi32_vdso.o ${.TARGET}" \
no-implicit-rule \
clean "cloudabi32_vdso_blob.o"
#
Provide the CloudABI vDSO to its executables. CloudABI executables already provide support for passing in vDSOs. This functionality is used by the emulator for OS X to inject system call handlers. On FreeBSD, we could use it to optimize calls to gettimeofday(), etc. Though I don't have any plans to optimize any system calls right now, let's go ahead and already pass in a vDSO. This will allow us to simplify the executables, as the traditional "syscall" shims can be removed entirely. It also means that we gain more flexibility with regards to adding and removing system calls. Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D7438
2016-08-10 23:02:41 +02:00
cloudabi64_vdso.o optional compat_cloudabi64 \
Rewrite the vDSOs for CloudABI in assembly. The reason why the old vDSOs were written in C using inline assembly was purely because they were embedded in the C library directly as static inline functions. This was practical during development, because it meant you could invoke system calls without any library dependencies. The vDSO was simply a copy of these functions. Now that we require the use of the vDSO, there is no longer any need for embedding them in C code directly. Rewriting them in assembly has the advantage that they are closer to ideal (less useless branching, less assumptions about registers remaining unclobbered by the kernel, etc). They are also easier to build, as they no longer depend on the C type information for CloudABI. Obtained from: https://github.com/NuxiNL/cloudabi
2016-08-21 09:28:38 +02:00
dependency "$S/contrib/cloudabi/cloudabi_vdso_x86_64.S" \
Move the linker script from cloudabi64/ to cloudabi/. It turns out that it works perfectly fine for generating 32-bits vDSOs as well. While there, get rid of the extraneous .s file extension.
2016-08-21 17:14:06 +02:00
compile-with "${CC} -x assembler-with-cpp -shared -nostdinc -nostdlib -Wl,-T$S/compat/cloudabi/cloudabi_vdso.lds $S/contrib/cloudabi/cloudabi_vdso_x86_64.S -o ${.TARGET}" \
Provide the CloudABI vDSO to its executables. CloudABI executables already provide support for passing in vDSOs. This functionality is used by the emulator for OS X to inject system call handlers. On FreeBSD, we could use it to optimize calls to gettimeofday(), etc. Though I don't have any plans to optimize any system calls right now, let's go ahead and already pass in a vDSO. This will allow us to simplify the executables, as the traditional "syscall" shims can be removed entirely. It also means that we gain more flexibility with regards to adding and removing system calls. Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D7438
2016-08-10 23:02:41 +02:00
no-obj no-implicit-rule \
clean "cloudabi64_vdso.o"
#
cloudabi64_vdso_blob.o optional compat_cloudabi64 \
dependency "cloudabi64_vdso.o" \
compile-with "${OBJCOPY} --input-target binary --output-target elf64-x86-64-freebsd --binary-architecture i386 cloudabi64_vdso.o ${.TARGET}" \
no-implicit-rule \
clean "cloudabi64_vdso_blob.o"
#
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 09:55:06 +02:00
linux32_genassym.o optional compat_linux32 \
dependency "$S/amd64/linux32/linux32_genassym.c" \
Exclude -flto when building *genassym.o The build process generates *assym.h using nm from *genassym.o (which is in turn created from *genassym.c). When compiling with link-time optimization (LTO) using -flto, .o files are LLVM bitcode, not ELF objects. This is not usable by genassym.sh, so remove -flto from those ${CC} invocations. Submitted by: George Rimar Reviewed by: dim MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D9659
2017-02-21 19:59:17 +01:00
compile-with "${CC} ${CFLAGS:N-flto:N-fno-common} -c ${.IMPSRC}" \
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 09:55:06 +02:00
no-obj no-implicit-rule \
clean "linux32_genassym.o"
#
linux32_assym.h optional compat_linux32 \
dependency "$S/kern/genassym.sh linux32_genassym.o" \
compile-with "sh $S/kern/genassym.sh linux32_genassym.o > ${.TARGET}" \
no-obj no-implicit-rule before-depend \
clean "linux32_assym.h"
#
Implement vdso - virtual dynamic shared object. Through vdso Linux exposes functions from kernel with proper DWARF CFI information so that it becomes easier to unwind through them. Using vdso is a mandatory for a thread cancelation && cleanup on a modern glibc. Differential Revision: https://reviews.freebsd.org/D1060
2015-05-24 17:28:17 +02:00
linux32_locore.o optional compat_linux32 \
dependency "linux32_assym.h $S/amd64/linux32/linux32_locore.s" \
linux vdso: pass -fPIC to the assembler, not linker -fPIC has no effect on linking although it seems to be ignored by GNU ld.bfd. However, it causes ld.lld to terminate with an invalid argument error. This is equivalent to r296057 but for the kernel (not modules) case. MFC after: 2 months Sponsored by: The FreeBSD Foundation
2017-06-03 05:40:11 +02:00
compile-with "${CC} -x assembler-with-cpp -DLOCORE -m32 -shared -s -pipe -I. -I$S -Werror -Wall -fPIC -fno-common -nostdinc -nostdlib -Wl,-T$S/amd64/linux32/linux32_vdso.lds.s -Wl,-soname=linux32_vdso.so,--eh-frame-hdr,-warn-common ${.IMPSRC} -o ${.TARGET}" \
Implement vdso - virtual dynamic shared object. Through vdso Linux exposes functions from kernel with proper DWARF CFI information so that it becomes easier to unwind through them. Using vdso is a mandatory for a thread cancelation && cleanup on a modern glibc. Differential Revision: https://reviews.freebsd.org/D1060
2015-05-24 17:28:17 +02:00
no-obj no-implicit-rule \
clean "linux32_locore.o"
#
linux32_vdso.so optional compat_linux32 \
dependency "linux32_locore.o" \
For objcopy, use --input-target and --output-target When building with gcc 4.9 and binutils 2.25, using '--input' and '--output' returns an error message: objcopy: option `--input' is ambiguous Reported by: Jenkins
2015-05-25 03:07:55 +02:00
compile-with "${OBJCOPY} --input-target binary --output-target elf64-x86-64-freebsd --binary-architecture i386 linux32_locore.o ${.TARGET}" \
Implement vdso - virtual dynamic shared object. Through vdso Linux exposes functions from kernel with proper DWARF CFI information so that it becomes easier to unwind through them. Using vdso is a mandatory for a thread cancelation && cleanup on a modern glibc. Differential Revision: https://reviews.freebsd.org/D1060
2015-05-24 17:28:17 +02:00
no-implicit-rule \
clean "linux32_vdso.so"
#
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 09:58:16 +01:00
ia32_genassym.o standard \
Complete the switch to the common 32 bit support code.
2003-08-23 02:58:33 +02:00
dependency "$S/compat/ia32/ia32_genassym.c" \
Exclude -flto when building *genassym.o The build process generates *assym.h using nm from *genassym.o (which is in turn created from *genassym.c). When compiling with link-time optimization (LTO) using -flto, .o files are LLVM bitcode, not ELF objects. This is not usable by genassym.sh, so remove -flto from those ${CC} invocations. Submitted by: George Rimar Reviewed by: dim MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D9659
2017-02-21 19:59:17 +01:00
compile-with "${CC} ${CFLAGS:N-flto:N-fno-common} -c ${.IMPSRC}" \
Add BASIC i386 binary support for the amd64 kernel. This is largely stolen from the ia64/ia32 code (indeed there was a repocopy), but I've redone the MD parts and added and fixed a few essential syscalls. It is sufficient to run i386 binaries like /bin/ls, /usr/bin/id (dynamic) and p4. The ia64 code has not implemented signal delivery, so I had to do that. Before you say it, yes, this does need to go in a common place. But we're in a freeze at the moment and I didn't want to risk breaking ia64. I will sort this out after the freeze so that the common code is in a common place. On the AMD64 side, this required adding segment selector context switch support and some other support infrastructure. The %fs/%gs etc code is hairy because loading %gs will clobber the kernel's current MSR_GSBASE setting. The segment selectors are not used by the kernel, so they're only changed at context switch time or when changing modes. This still needs to be optimized. Approved by: re (amd64/* blanket)
2003-05-14 06:10:49 +02:00
no-obj no-implicit-rule \
clean "ia32_genassym.o"
#
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 09:58:16 +01:00
ia32_assym.h standard \
Add BASIC i386 binary support for the amd64 kernel. This is largely stolen from the ia64/ia32 code (indeed there was a repocopy), but I've redone the MD parts and added and fixed a few essential syscalls. It is sufficient to run i386 binaries like /bin/ls, /usr/bin/id (dynamic) and p4. The ia64 code has not implemented signal delivery, so I had to do that. Before you say it, yes, this does need to go in a common place. But we're in a freeze at the moment and I didn't want to risk breaking ia64. I will sort this out after the freeze so that the common code is in a common place. On the AMD64 side, this required adding segment selector context switch support and some other support infrastructure. The %fs/%gs etc code is hairy because loading %gs will clobber the kernel's current MSR_GSBASE setting. The segment selectors are not used by the kernel, so they're only changed at context switch time or when changing modes. This still needs to be optimized. Approved by: re (amd64/* blanket)
2003-05-14 06:10:49 +02:00
dependency "$S/kern/genassym.sh ia32_genassym.o" \
sys/conf: pass NMFLAGS to nm(1) via genassym.sh.
2015-08-15 00:58:32 +02:00
compile-with "env NM='${NM}' NMFLAGS='${NMFLAGS}' sh $S/kern/genassym.sh ia32_genassym.o > ${.TARGET}" \
Add BASIC i386 binary support for the amd64 kernel. This is largely stolen from the ia64/ia32 code (indeed there was a repocopy), but I've redone the MD parts and added and fixed a few essential syscalls. It is sufficient to run i386 binaries like /bin/ls, /usr/bin/id (dynamic) and p4. The ia64 code has not implemented signal delivery, so I had to do that. Before you say it, yes, this does need to go in a common place. But we're in a freeze at the moment and I didn't want to risk breaking ia64. I will sort this out after the freeze so that the common code is in a common place. On the AMD64 side, this required adding segment selector context switch support and some other support infrastructure. The %fs/%gs etc code is hairy because loading %gs will clobber the kernel's current MSR_GSBASE setting. The segment selectors are not used by the kernel, so they're only changed at context switch time or when changing modes. This still needs to be optimized. Approved by: re (amd64/* blanket)
2003-05-14 06:10:49 +02:00
no-obj no-implicit-rule before-depend \
clean "ia32_assym.h"
#
Add rules for font.h atkbdmap.h ukbdmap.h so more of LINT can be built.
2004-03-03 10:37:44 +01:00
font.h optional sc_dflt_font \
compile-with "uudecode < /usr/share/syscons/fonts/${SC_DFLT_FONT}-8x16.fnt && file2c 'static u_char dflt_font_16[16*256] = {' '};' < ${SC_DFLT_FONT}-8x16 > font.h && uudecode < /usr/share/syscons/fonts/${SC_DFLT_FONT}-8x14.fnt && file2c 'static u_char dflt_font_14[14*256] = {' '};' < ${SC_DFLT_FONT}-8x14 >> font.h && uudecode < /usr/share/syscons/fonts/${SC_DFLT_FONT}-8x8.fnt && file2c 'static u_char dflt_font_8[8*256] = {' '};' < ${SC_DFLT_FONT}-8x8 >> font.h" \
no-obj no-implicit-rule before-depend \
clean "font.h ${SC_DFLT_FONT}-8x14 ${SC_DFLT_FONT}-8x16 ${SC_DFLT_FONT}-8x8"
#
atkbdmap.h optional atkbd_dflt_keymap \
simplify compile-time default keyboard map generation In r296926 the -P <path> option was added to kbdcontrol, which enables this change for a simplified compile-time default keymap build process. PR: 193865 Reviewed by: Oliver Pinter Tested by: Oliver Pinter MFC After: 1 month Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D5708
2016-03-28 21:51:45 +02:00
compile-with "kbdcontrol -P ${S:S/sys$/share/}/vt/keymaps -P ${S:S/sys$/share/}/syscons/keymaps -L ${ATKBD_DFLT_KEYMAP} | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > atkbdmap.h" \
Add rules for font.h atkbdmap.h ukbdmap.h so more of LINT can be built.
2004-03-03 10:37:44 +01:00
no-obj no-implicit-rule before-depend \
clean "atkbdmap.h"
#
ukbdmap.h optional ukbd_dflt_keymap \
simplify compile-time default keyboard map generation In r296926 the -P <path> option was added to kbdcontrol, which enables this change for a simplified compile-time default keymap build process. PR: 193865 Reviewed by: Oliver Pinter Tested by: Oliver Pinter MFC After: 1 month Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D5708
2016-03-28 21:51:45 +02:00
compile-with "kbdcontrol -P ${S:S/sys$/share/}/vt/keymaps -P ${S:S/sys$/share/}/syscons/keymaps -L ${UKBD_DFLT_KEYMAP} | sed -e 's/^static keymap_t.* = /static keymap_t key_map = /' -e 's/^static accentmap_t.* = /static accentmap_t accent_map = /' > ukbdmap.h" \
Add rules for font.h atkbdmap.h ukbdmap.h so more of LINT can be built.
2004-03-03 10:37:44 +01:00
no-obj no-implicit-rule before-depend \
clean "ukbdmap.h"
#
Import the first release of HighPoint RocketRAID 27xx SAS 6Gb/s HBA card driver. This driver works for FreeBSD/i386 and FreeBSD/amd64 platforms. Many thanks to HighPoint for providing this driver. MFC after: 2 weeks
2011-12-29 00:26:58 +01:00
hpt27xx_lib.o optional hpt27xx \
dependency "$S/dev/hpt27xx/amd64-elf.hpt27xx_lib.o.uu" \
compile-with "uudecode < $S/dev/hpt27xx/amd64-elf.hpt27xx_lib.o.uu" \
no-implicit-rule
Import HighPoint DC Series Data Center HBA (DC7280 and R750) driver. This driver works for FreeBSD/i386 and FreeBSD/amd64 platforms. Many thanks to HighPoint for providing this driver. MFC after: 1 day
2013-07-06 09:49:41 +02:00
#
Hook up the hptmv driver for amd64. MFC After: 3 days
2005-09-08 05:29:18 +02:00
hptmvraid.o optional hptmv \
dependency "$S/dev/hptmv/amd64-elf.raid.o.uu" \
compile-with "uudecode < $S/dev/hptmv/amd64-elf.raid.o.uu" \
no-implicit-rule
Import HighPoint DC Series Data Center HBA (DC7280 and R750) driver. This driver works for FreeBSD/i386 and FreeBSD/amd64 platforms. Many thanks to HighPoint for providing this driver. MFC after: 1 day
2013-07-06 09:49:41 +02:00
#
hptnr_lib.o optional hptnr \
dependency "$S/dev/hptnr/amd64-elf.hptnr_lib.o.uu" \
compile-with "uudecode < $S/dev/hptnr/amd64-elf.hptnr_lib.o.uu" \
no-implicit-rule
#
Add the 'hptrr' driver for supporting the following Highpoint RocketRAID cards: o RocketRAID 172x series o RocketRAID 174x series o RocketRAID 2210 o RocketRAID 222x series o RocketRAID 2240 o RocketRAID 230x series o RocketRAID 231x series o RocketRAID 232x series o RocketRAID 2340 o RocketRAID 2522 Many thanks to Highpoint for their continued support of FreeBSD. Submitted by: Highpoint
2007-12-15 01:56:17 +01:00
hptrr_lib.o optional hptrr \
dependency "$S/dev/hptrr/amd64-elf.hptrr_lib.o.uu" \
compile-with "uudecode < $S/dev/hptrr/amd64-elf.hptrr_lib.o.uu" \
no-implicit-rule
#
Port acpica to amd64. Approved by: re (amd64/* blanket)
2003-05-31 08:47:05 +02:00
amd64/acpica/acpi_machdep.c optional acpi
Move i386-inherited logic of building ACPI headers for acpi_wakeup.c into better places and remove intermediate makefile and shell scripts. This makes parallel kernel build little bit safer for amd64.
2010-07-12 23:08:35 +02:00
acpi_wakecode.o optional acpi \
Rename assym.s to assym.inc assym is only to be included by other .s files, and should never actually be assembled by itself. Reviewed by: imp, bdrewery (earlier) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D14180
2018-03-20 18:58:51 +01:00
dependency "$S/amd64/acpica/acpi_wakecode.S assym.inc" \
Move i386-inherited logic of building ACPI headers for acpi_wakeup.c into better places and remove intermediate makefile and shell scripts. This makes parallel kernel build little bit safer for amd64.
2010-07-12 23:08:35 +02:00
compile-with "${NORMAL_S}" \
Initial suspend/resume support for amd64. This code is heavily inspired by Takanori Watanabe's experimental SMP patch for i386 and large portion was shamelessly cut and pasted from Peter Wemm's AP boot code.
2009-03-17 01:48:11 +01:00
no-obj no-implicit-rule before-depend \
Move i386-inherited logic of building ACPI headers for acpi_wakeup.c into better places and remove intermediate makefile and shell scripts. This makes parallel kernel build little bit safer for amd64.
2010-07-12 23:08:35 +02:00
clean "acpi_wakecode.o"
acpi_wakecode.bin optional acpi \
dependency "acpi_wakecode.o" \
Replace a bare use of 'objcopy' with ${OBJCOPY} for easier cross compilation in environments where 'objcopy' is spelled differently. Submitted by: John Van Horne <jvanhorne@juniper.net>
2012-09-12 15:58:18 +02:00
compile-with "${OBJCOPY} -S -O binary acpi_wakecode.o ${.TARGET}" \
Move i386-inherited logic of building ACPI headers for acpi_wakeup.c into better places and remove intermediate makefile and shell scripts. This makes parallel kernel build little bit safer for amd64.
2010-07-12 23:08:35 +02:00
no-obj no-implicit-rule before-depend \
clean "acpi_wakecode.bin"
acpi_wakecode.h optional acpi \
dependency "acpi_wakecode.bin" \
compile-with "file2c -sx 'static char wakecode[] = {' '};' < acpi_wakecode.bin > ${.TARGET}" \
no-obj no-implicit-rule before-depend \
clean "acpi_wakecode.h"
acpi_wakedata.h optional acpi \
dependency "acpi_wakecode.o" \
Stop hard coding nm(1) and make it overridable.
2010-10-15 01:31:58 +02:00
compile-with '${NM} -n --defined-only acpi_wakecode.o | while read offset dummy what; do echo "#define $${what} 0x$${offset}"; done > ${.TARGET}' \
Move i386-inherited logic of building ACPI headers for acpi_wakeup.c into better places and remove intermediate makefile and shell scripts. This makes parallel kernel build little bit safer for amd64.
2010-07-12 23:08:35 +02:00
no-obj no-implicit-rule before-depend \
clean "acpi_wakedata.h"
Initial suspend/resume support for amd64. This code is heavily inspired by Takanori Watanabe's experimental SMP patch for i386 and large portion was shamelessly cut and pasted from Peter Wemm's AP boot code.
2009-03-17 01:48:11 +01:00
#
Fixed profiling of trap, syscall and interrupt handlers and some ordinary functions, essentially by backing out half of rev.1.115 of amd64/exception.S. The handlers must be between certain labels for the purposes of profiling, and this was broken by scattering them in separately compiled .S files, especially for ordinary functions that ended up between the labels. Merge the files by #including them as before, except with different pathnames and better comments and organization. Changes to the scattered files are minimal -- just move the labels to the file that does the #includes. This also partly fixes profiling of IPIs -- all IPI handlers are now correctly classified as interrupt handlers, but many are still missing mcount calls.
2004-05-24 14:08:56 +02:00
#amd64/amd64/apic_vector.S standard
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 09:58:16 +01:00
amd64/amd64/atomic.c standard
Converge towards i386. I originally resisted creating <machine/pc/bios.h> because it was mostly irrelevant - except for the silly BIOS_PADDRTOVADDR etc macros. Along the way of working around this, I missed a few things. * Make syscons properly inherit the bios capslock/shiftlock/etc state like i386 does. Note that we cannot inherit the bios key repeat rate because that requires a bios call (which is impossible for us). * Give syscons the ability to beep on amd64. Oops. While here, make bios.c compile and add it to files.amd64.
2004-09-24 03:08:34 +02:00
amd64/amd64/bios.c standard
Add BPF Just-In-Time compiler support for ng_bpf(4). The sysctl is changed from net.bpf.jitter.enable to net.bpf_jitter.enable and this controls both bpf(4) and ng_bpf(4) now.
2005-12-07 22:30:47 +01:00
amd64/amd64/bpf_jit_machdep.c optional bpf_jitter
Spell cpu_switch correctly.
2003-05-03 05:30:29 +02:00
amd64/amd64/cpu_switch.S standard
Add ddb machdep bits. Approved by: re (amd64 bits)
2003-05-30 03:03:43 +02:00
amd64/amd64/db_disasm.c optional ddb
amd64/amd64/db_interface.c optional ddb
amd64/amd64/db_trace.c optional ddb
To prepare for adding EFI runtime services support on arm64 move the machine independent parts of the existing code to a new file that can be shared between amd64 and arm64. Reviewed by: kib (previous version), imp Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D12434
2017-10-01 21:52:47 +02:00
amd64/amd64/efirt_machdep.c optional efirt
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 04:59:24 +02:00
amd64/amd64/elf_machdep.c standard
Rename amd64/*.s to amd64/*.S
2003-05-03 02:19:42 +02:00
amd64/amd64/exception.S standard
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 09:58:16 +01:00
amd64/amd64/fpu.c standard
Hook the GDB backend into the build.
2004-07-11 01:31:17 +02:00
amd64/amd64/gdb_machdep.c optional gdb
Compile in in_cksum* implementations for both IPv6 and IPv6. While in_pseudo() etc. is often used in offloading feature support, in_cksum() is mostly used to fix some broken hardware. Keeping both around for the moment allows us to compile NIC drivers even in an IPv6 only environment without the need to mangle them with #ifdef INETs in a way they are not prepared for. This will leave some dead code paths that will not be exercised for IPv6. Reviewed by: gnn Sponsored by: The FreeBSD Foundation Sponsored by: iXsystems MFC after: 3 days
2011-04-20 14:58:30 +02:00
amd64/amd64/in_cksum.c optional inet | inet6
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 04:59:24 +02:00
amd64/amd64/initcpu.c standard
Break out the MI part of the /dev/[k]mem and /dev/io drivers into their own directory and module, leaving the MD parts in the MD area (the MD parts _are_ part of the modules). /dev/mem and /dev/io are now loadable modules, thus taking us one step further towards a kernel created entirely out of modules. Of course, there is nothing preventing the kernel from having these statically compiled.
2004-08-01 13:40:54 +02:00
amd64/amd64/io.c optional io
Rename amd64/*.s to amd64/*.S
2003-05-03 02:19:42 +02:00
amd64/amd64/locore.S standard no-obj
xen: add PV/PVH kernel entry point Add the PV/PVH entry point and the low level functions for PVH early initialization. Approved by: gibbs Sponsored by: Citrix Systems R&D amd64/amd64/genassym.c: - Add __FreeBSD_version define to assym.s so it can be used for the Xen notes. amd64/amd64/locore.S: - Make bootstack global so it can be used from Xen kernel entry point. amd64/amd64/xen-locore.S: - Add Xen notes to the kernel. - Add the Xen PV entry point, that is going to call hammer_time_xen. amd64/include/asmacros.h: - Add ELFNOTE macros. i386/xen/xen_machdep.c: - Define HYPERVISOR_start_info for the XEN i386 PV port, which is going to be used in some shared code between PV and PVH. x86/xen/hvm.c: - Define HYPERVISOR_start_info for the PVH port. x86/xen/pv.c: - Introduce hammer_time_xen which is going to perform early setup for Xen PVH: - Setup shared Xen variables start_info, shared_info and xen_store. - Set guest type. - Create initial page tables as FreeBSD expects to find them. - Call into native init function (hammer_time). xen/xen-os.h: - Declare HYPERVISOR_start_info. conf/files.amd64: - Add amd64/amd64/locore.S and x86/xen/pv.c to the list of files.
2014-03-11 11:07:01 +01:00
amd64/amd64/xen-locore.S optional xenhvm
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 04:59:24 +02:00
amd64/amd64/machdep.c standard
Break out the MI part of the /dev/[k]mem and /dev/io drivers into their own directory and module, leaving the MD parts in the MD area (the MD parts _are_ part of the modules). /dev/mem and /dev/io are now loadable modules, thus taking us one step further towards a kernel created entirely out of modules. Of course, there is nothing preventing the kernel from having these statically compiled.
2004-08-01 13:40:54 +02:00
amd64/amd64/mem.c optional mem
Introduce minidumps. Full physical memory crash dumps are still available via the debug.minidump sysctl and tunable. Traditional dumps store all physical memory. This was once a good thing when machines had a maximum of 64M of ram and 1GB of kvm. These days, machines often have many gigabytes of ram and a smaller amount of kvm. libkvm+kgdb don't have a way to access physical ram that is not mapped into kvm at the time of the crash dump, so the extra ram being dumped is mostly wasted. Minidumps invert the process. Instead of dumping physical memory in in order to guarantee that all of kvm's backing is dumped, minidumps instead dump only memory that is actively mapped into kvm. amd64 has a direct map region that things like UMA use. Obviously we cannot dump all of the direct map region because that is effectively an old style all-physical-memory dump. Instead, introduce a bitmap and two helper routines (dump_add_page(pa) and dump_drop_page(pa)) that allow certain critical direct map pages to be included in the dump. uma_machdep.c's allocator is the intended consumer. Dumps are a custom format. At the very beginning of the file is a header, then a copy of the message buffer, then the bitmap of pages present in the dump, then the final level of the kvm page table trees (2MB mappings are expanded into a 4K page mappings), then the sparse physical pages according to the bitmap. libkvm can now conveniently access the kvm page table entries. Booting my test 8GB machine, forcing it into ddb and forcing a dump leads to a 48MB minidump. While this is a best case, I expect minidumps to be in the 100MB-500MB range. Obviously, never larger than physical memory of course. minidumps are on by default. It would want be necessary to turn them off if it was necessary to debug corrupt kernel page table management as that would mess up minidumps as well. Both minidumps and regular dumps are supported on the same machine.
2006-04-21 06:24:50 +02:00
amd64/amd64/minidump_machdep.c standard
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 09:58:16 +01:00
amd64/amd64/mp_machdep.c optional smp
amd64/amd64/mpboot.S optional smp
Eliminate compilation warnings due to the use of non-static inlines through the introduction and use of the __gnu89_inline attribute. Submitted by: bde (i386) MFC after: 3 days
2007-12-09 22:00:36 +01:00
amd64/amd64/pmap.c standard
Fixed insertion sort error in previous commit (prof_machdep.c). Fixed apparently-intentional disorder of the crypto files. Lists of files should be sorted first on the pathname, not on the option name or subsystem.
2004-05-24 11:55:02 +02:00
amd64/amd64/prof_machdep.c optional profiling-routine
Add support for the extended FPU states on amd64, both for native 64bit and 32bit ABIs. As a side-effect, it enables AVX on capable CPUs. In particular: - Query the CPU support for XSAVE, list of the supported extensions and the required size of FPU save area. The hw.use_xsave tunable is provided for disabling XSAVE, and hw.xsave_mask may be used to select the enabled extensions. - Remove the FPU save area from PCB and dynamically allocate the (run-time sized) user save area on the top of the kernel stack, right above the PCB. Reorganize the thread0 PCB initialization to postpone it after BSP is queried for save area size. - The dumppcb, stoppcbs and susppcbs now do not carry the FPU state as well. FPU state is only useful for suspend, where it is saved in dynamically allocated suspfpusave area. - Use XSAVE and XRSTOR to save/restore FPU state, if supported and enabled. - Define new mcontext_t flag _MC_HASFPXSTATE, indicating that mcontext_t has a valid pointer to out-of-struct extended FPU state. Signal handlers are supplied with stack-allocated fpu state. The sigreturn(2) and setcontext(2) syscall honour the flag, allowing the signal handlers to inspect and manipilate extended state in the interrupted context. - The getcontext(2) never returns extended state, since there is no place in the fixed-sized mcontext_t to place variable-sized save area. And, since mcontext_t is embedded into ucontext_t, makes it impossible to fix in a reasonable way. Instead of extending getcontext(2) syscall, provide a sysarch(2) facility to query extended FPU state. - Add ptrace(2) support for getting and setting extended state; while there, implement missed PT_I386_{GET,SET}XMMREGS for 32bit binaries. - Change fpu_kern KPI to not expose struct fpu_kern_ctx layout to consumers, making it opaque. Internally, struct fpu_kern_ctx now contains a space for the extended state. Convert in-kernel consumers of fpu_kern KPI both on i386 and amd64. First version of the support for AVX was submitted by Tim Bird <tim.bird am sony com> on behalf of Sony. This version was written from scratch. Tested by: pho (previous version), Yamagi Burmeister <lists yamagi org> MFC after: 1 month
2012-01-21 18:45:27 +01:00
amd64/amd64/ptrace_machdep.c standard
Rename amd64/*.s to amd64/*.S
2003-05-03 02:19:42 +02:00
amd64/amd64/sigtramp.S standard
amd64/amd64/support.S standard
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 04:59:24 +02:00
amd64/amd64/sys_machdep.c standard
amd64/amd64/trap.c standard
Introduce uiomove_fromphys(). This is a variant of uiomove() that takes a collection of physical pages as the source. On amd64 it is implemented using the direct virtual-to-physical map.
2004-03-20 20:36:29 +01:00
amd64/amd64/uio_machdep.c standard
MFia64 Move uma_small_alloc() and uma_small_free() to uma_machdep.c.
2003-10-14 07:51:31 +02:00
amd64/amd64/uma_machdep.c standard
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 04:59:24 +02:00
amd64/amd64/vm_machdep.c standard
Make execution of 32-bit CloudABI executables work on amd64. A nice thing about requiring a vDSO is that it makes it incredibly easy to provide full support for running 32-bit processes on 64-bit systems. Instead of letting the kernel be responsible for composing/decomposing 64-bit arguments across multiple registers/stack slots, all of this can now be done in the vDSO. This means that there is no need to provide duplicate copies of certain system calls, like the sys_lseek() and freebsd32_lseek() we have for COMPAT_FREEBSD32. This change imports a new vDSO from the CloudABI repository that has automatically generated code in it that copies system call arguments into a buffer, padding them to eight bytes and zero-extending any pointers/size_t arguments. After returning from the kernel, it does the inverse: extracting return values, in the process truncating pointers/size_t values to 32 bits. Obtained from: https://github.com/NuxiNL/cloudabi
2016-08-24 12:51:33 +02:00
amd64/cloudabi32/cloudabi32_sysvec.c optional compat_cloudabi32
Add a sysentvec for CloudABI on x86-64. Summary: For CloudABI we need to put two things on the stack of new processes: the argument data (a binary blob; not strings) and a startup data structure. The startup data structure contains interesting things such as a pointer to the ELF program header, the thread ID of the initial thread, a stack smashing protection canary, and a pointer to the argument data. Fetching system call arguments and setting the return value is similar to FreeBSD. The only differences are that system call 0 does not exist and that we call into cloudabi_convert_errno() to convert the error code. We also need this function in a couple of other places, so we'd better reuse it here. Reviewers: dchagin, kib Reviewed By: kib Subscribers: imp Differential Revision: https://reviews.freebsd.org/D3098
2015-07-16 20:24:06 +02:00
amd64/cloudabi64/cloudabi64_sysvec.c optional compat_cloudabi64
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 09:58:16 +01:00
amd64/pci/pci_cfgreg.c optional pci
Allow DTrace to be compiled-in to the kernel. This will require for AArch64 as we dont have modules yet. Sponsored by: HEIF5 Sponsored by: ARM Ltd. Differential Revision: https://reviews.freebsd.org/D1997
2015-06-10 17:53:39 +02:00
cddl/contrib/opensolaris/common/atomic/amd64/opensolaris_atomic.S optional zfs | dtrace compile-with "${ZFS_S}"
cddl/dev/dtrace/amd64/dtrace_asm.S optional dtrace compile-with "${DTRACE_S}"
cddl/dev/dtrace/amd64/dtrace_subr.c optional dtrace compile-with "${DTRACE_C}"
cddl/dev/fbt/x86/fbt_isa.c optional dtrace_fbt | dtraceall compile-with "${FBT_C}"
cddl/dev/dtrace/x86/dis_tables.c optional dtrace_fbt | dtraceall compile-with "${DTRACE_C}"
Merge {amd64,i386}/instr_size.c into x86_instr_size.c. Also reduce the diff between us and upstream: the input data model will always be DATAMODEL_NATIVE because of a bug (p_model is never set but is always initialized to 0), so we don't need to override the caller anyway. This change is also necessary to support the pid provider for 32-bit processes on amd64. MFC after: 2 weeks
2016-07-20 02:02:10 +02:00
cddl/dev/dtrace/x86/instr_size.c optional dtrace_fbt | dtraceall compile-with "${DTRACE_C}"
Crypto(4) driver for AESNI. The aeskeys_{amd64,i386}.S content was mostly obtained from OpenBSD, no objections to the license from core. Hardware provided by: Sentex Communications Tested by: fabient, pho (previous versions) MFC after: 1 month
2010-07-23 13:00:46 +02:00
crypto/aesni/aeskeys_amd64.S optional aesni
crypto/aesni/aesni.c optional aesni
Add some new modes to OpenCrypto. These modes are AES-ICM (can be used for counter mode), and AES-GCM. Both of these modes have been added to the aesni module. Included is a set of tests to validate that the software and aesni module calculate the correct values. These use the NIST KAT test vectors. To run the test, you will need to install a soon to be committed port, nist-kat that will install the vectors. Using a port is necessary as the test vectors are around 25MB. All the man pages were updated. I have added a new man page, crypto.7, which includes a description of how to use each mode. All the new modes and some other AES modes are present. It would be good for someone else to go through and document the other modes. A new ioctl was added to support AEAD modes which AES-GCM is one of them. Without this ioctl, it is not possible to test AEAD modes from userland. Add a timing safe bcmp for use to compare MACs. Previously we were using bcmp which could leak timing info and result in the ability to forge messages. Add a minor optimization to the aesni module so that single segment mbufs don't get copied and instead are updated in place. The aesni module needs to be updated to support blocked IO so segmented mbufs don't have to be copied. We require that the IV be specified for all calls for both GCM and ICM. This is to ensure proper use of these functions. Obtained from: p4: //depot/projects/opencrypto Relnotes: yes Sponsored by: FreeBSD Foundation Sponsored by: NetGate
2014-12-12 20:56:36 +01:00
aesni_ghash.o optional aesni \
dependency "$S/crypto/aesni/aesni_ghash.c" \
For clang, disable -Wcast-qual warnings for specific aesni files, since clang 3.6.0 will emit a number of such warnings for those files, and they are partially contributed code.
2015-01-30 19:17:17 +01:00
compile-with "${CC} -c ${CFLAGS:C/^-O2$/-O3/:N-nostdinc} ${WERROR} ${NO_WCAST_QUAL} ${PROF} -mmmx -msse -msse4 -maes -mpclmul ${.IMPSRC}" \
Add some new modes to OpenCrypto. These modes are AES-ICM (can be used for counter mode), and AES-GCM. Both of these modes have been added to the aesni module. Included is a set of tests to validate that the software and aesni module calculate the correct values. These use the NIST KAT test vectors. To run the test, you will need to install a soon to be committed port, nist-kat that will install the vectors. Using a port is necessary as the test vectors are around 25MB. All the man pages were updated. I have added a new man page, crypto.7, which includes a description of how to use each mode. All the new modes and some other AES modes are present. It would be good for someone else to go through and document the other modes. A new ioctl was added to support AEAD modes which AES-GCM is one of them. Without this ioctl, it is not possible to test AEAD modes from userland. Add a timing safe bcmp for use to compare MACs. Previously we were using bcmp which could leak timing info and result in the ability to forge messages. Add a minor optimization to the aesni module so that single segment mbufs don't get copied and instead are updated in place. The aesni module needs to be updated to support blocked IO so segmented mbufs don't have to be copied. We require that the IV be specified for all calls for both GCM and ICM. This is to ensure proper use of these functions. Obtained from: p4: //depot/projects/opencrypto Relnotes: yes Sponsored by: FreeBSD Foundation Sponsored by: NetGate
2014-12-12 20:56:36 +01:00
no-implicit-rule \
clean "aesni_ghash.o"
Use the fact that the AES-NI instructions can be pipelined to improve performance... Use SSE2 instructions for calculating the XTS tweek factor... Let the compiler do more work and handle register allocation by using intrinsics, now only the key schedule is in assembly... Replace .byte hard coded instructions w/ the proper instructions now that both clang and gcc support them... On my machine, pulling the code to userland I saw performance go from ~150MB/sec to 2GB/sec in XTS mode. GELI on GNOP saw a more modest increase of about 3x due to other system overhead (geom and opencrypto)... These changes allow almost full disk io rate w/ geli... Reviewed by: -current, -security Thanks to: Mike Hamburg for the XTS tweek algorithm
2013-09-03 20:31:23 +02:00
aesni_wrap.o optional aesni \
dependency "$S/crypto/aesni/aesni_wrap.c" \
For clang, disable -Wcast-qual warnings for specific aesni files, since clang 3.6.0 will emit a number of such warnings for those files, and they are partially contributed code.
2015-01-30 19:17:17 +01:00
compile-with "${CC} -c ${CFLAGS:C/^-O2$/-O3/:N-nostdinc} ${WERROR} ${NO_WCAST_QUAL} ${PROF} -mmmx -msse -msse4 -maes ${.IMPSRC}" \
Use the fact that the AES-NI instructions can be pipelined to improve performance... Use SSE2 instructions for calculating the XTS tweek factor... Let the compiler do more work and handle register allocation by using intrinsics, now only the key schedule is in assembly... Replace .byte hard coded instructions w/ the proper instructions now that both clang and gcc support them... On my machine, pulling the code to userland I saw performance go from ~150MB/sec to 2GB/sec in XTS mode. GELI on GNOP saw a more modest increase of about 3x due to other system overhead (geom and opencrypto)... These changes allow almost full disk io rate w/ geli... Reviewed by: -current, -security Thanks to: Mike Hamburg for the XTS tweek algorithm
2013-09-03 20:31:23 +02:00
no-implicit-rule \
clean "aesni_wrap.o"
Merge projects/ipsec into head/. Small summary ------------- o Almost all IPsec releated code was moved into sys/netipsec. o New kernel modules added: ipsec.ko and tcpmd5.ko. New kernel option IPSEC_SUPPORT added. It enables support for loading and unloading of ipsec.ko and tcpmd5.ko kernel modules. o IPSEC_NAT_T option was removed. Now NAT-T support is enabled by default. The UDP_ENCAP_ESPINUDP_NON_IKE encapsulation type support was removed. Added TCP/UDP checksum handling for inbound packets that were decapsulated by transport mode SAs. setkey(8) modified to show run-time NAT-T configuration of SA. o New network pseudo interface if_ipsec(4) added. For now it is build as part of ipsec.ko module (or with IPSEC kernel). It implements IPsec virtual tunnels to create route-based VPNs. o The network stack now invokes IPsec functions using special methods. The only one header file <netipsec/ipsec_support.h> should be included to declare all the needed things to work with IPsec. o All IPsec protocols handlers (ESP/AH/IPCOMP protosw) were removed. Now these protocols are handled directly via IPsec methods. o TCP_SIGNATURE support was reworked to be more close to RFC. o PF_KEY SADB was reworked: - now all security associations stored in the single SPI namespace, and all SAs MUST have unique SPI. - several hash tables added to speed up lookups in SADB. - SADB now uses rmlock to protect access, and concurrent threads can do SA lookups in the same time. - many PF_KEY message handlers were reworked to reflect changes in SADB. - SADB_UPDATE message was extended to support new PF_KEY headers: SADB_X_EXT_NEW_ADDRESS_SRC and SADB_X_EXT_NEW_ADDRESS_DST. They can be used by IKE daemon to change SA addresses. o ipsecrequest and secpolicy structures were cardinally changed to avoid locking protection for ipsecrequest. Now we support only limited number (4) of bundled SAs, but they are supported for both INET and INET6. o INPCB security policy cache was introduced. Each PCB now caches used security policies to avoid SP lookup for each packet. o For inbound security policies added the mode, when the kernel does check for full history of applied IPsec transforms. o References counting rules for security policies and security associations were changed. The proper SA locking added into xform code. o xform code was also changed. Now it is possible to unregister xforms. tdb_xxx structures were changed and renamed to reflect changes in SADB/SPDB, and changed rules for locking and refcounting. Reviewed by: gnn, wblock Obtained from: Yandex LLC Relnotes: yes Sponsored by: Yandex LLC Differential Revision: https://reviews.freebsd.org/D9352
2017-02-06 09:49:57 +01:00
crypto/blowfish/bf_enc.c optional crypto | ipsec | ipsec_support
crypto/des/des_enc.c optional crypto | ipsec | \
ipsec_support | netsmb
aesni(4): Add support for x86 SHA intrinsics Some x86 class CPUs have accelerated intrinsics for SHA1 and SHA256. Provide this functionality on CPUs that support it. This implements CRYPTO_SHA1, CRYPTO_SHA1_HMAC, and CRYPTO_SHA2_256_HMAC. Correctness: The cryptotest.py suite in tests/sys/opencrypto has been enhanced to verify SHA1 and SHA256 HMAC using standard NIST test vectors. The test passes on this driver. Additionally, jhb's cryptocheck tool has been used to compare various random inputs against OpenSSL. This test also passes. Rough performance averages on AMD Ryzen 1950X (4kB buffer): aesni: SHA1: ~8300 Mb/s SHA256: ~8000 Mb/s cryptosoft: ~1800 Mb/s SHA256: ~1800 Mb/s So ~4.4-4.6x speedup depending on algorithm choice. This is consistent with the results the Linux folks saw for 4kB buffers. The driver borrows SHA update code from sys/crypto sha1 and sha256. The intrinsic step function comes from Intel under a 3-clause BSDL.[0] The intel_sha_extensions_sha<foo>_intrinsic.c files were renamed and lightly modified (added const, resolved a warning or two; included the sha_sse header to declare the functions). [0]: https://software.intel.com/en-us/articles/intel-sha-extensions-implementations Reviewed by: jhb Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12452
2017-09-27 01:12:32 +02:00
intel_sha1.o optional aesni \
dependency "$S/crypto/aesni/intel_sha1.c" \
compile-with "${CC} -c ${CFLAGS:C/^-O2$/-O3/:N-nostdinc} ${WERROR} ${PROF} -mmmx -msse -msse4 -msha ${.IMPSRC}" \
no-implicit-rule \
clean "intel_sha1.o"
intel_sha256.o optional aesni \
dependency "$S/crypto/aesni/intel_sha256.c" \
compile-with "${CC} -c ${CFLAGS:C/^-O2$/-O3/:N-nostdinc} ${WERROR} ${PROF} -mmmx -msse -msse4 -msha ${.IMPSRC}" \
no-implicit-rule \
clean "intel_sha256.o"
Connect padlock(4) to amd64 build for VIA Nano processors.
2009-01-12 20:23:46 +01:00
crypto/via/padlock.c optional padlock
crypto/via/padlock_cipher.c optional padlock
crypto/via/padlock_hash.c optional padlock
Fix a mis-sort.
2004-12-21 03:07:38 +01:00
dev/acpica/acpi_if.m standard
Only enable the hpet driver on x86 hardware, it doesn't exist on arm64. Sponsored by: The FreeBSD Foundation
2015-04-28 18:51:48 +02:00
dev/acpica/acpi_hpet.c optional acpi
Only build the ACPI PCI drivers on x86, they are unlikely to be used on arm64 without dignificant changes. Obtained from: ABT Systems Ltd Sponsored by: The FreeBSD Foundation
2017-02-06 15:41:34 +01:00
dev/acpica/acpi_pci.c optional acpi pci
dev/acpica/acpi_pci_link.c optional acpi pci
dev/acpica/acpi_pcib.c optional acpi pci
dev/acpica/acpi_pcib_acpi.c optional acpi pci
dev/acpica/acpi_pcib_pci.c optional acpi pci
Only build acpi_timer.c on x86, it fails on arm64 as it attempts to access an invalid address. It is also unneeded on arm64 as we use the ARM Generic Timer driver. Obtained from: ABT Systems Ltd Sponsored by: The FreeBSD Foundation
2016-11-22 19:13:04 +01:00
dev/acpica/acpi_timer.c optional acpi
* Driver for ACPI WMI (Windows Management Instrumentation) * Driver for ACPI HP extra functionations, which required ACPI WMI driver. Submitted by: Michael <freebsdusb at bindone.de> Approved by: re MFC after: 2 weeks
2009-06-23 15:17:25 +02:00
dev/acpi_support/acpi_wmi_if.m standard
- Add few VIA bridges to agp_via.c and connect it to amd64 build as they support Intel Core/Core 2 and VIA Nano processors. - Align "optional agp" in conf/files.* for consistency while I am here.
2009-01-23 18:48:18 +01:00
dev/agp/agp_amd64.c optional agp
dev/agp/agp_i810.c optional agp
dev/agp/agp_via.c optional agp
amdsbwd: new driver for AMD SB600/SB7xx watchdog timer The hardware is compliant with WDRT specification, so I originally considered including generic WDRT watchdog support, but decided against it, because I couldn't find anyone to the code for me. WDRT seems to be not very popular. Besides, generic WDRT porbably requires a slightly different driver approach. Reviewed by: des, gavin, rpaulo MFC after: 3 weeks
2009-11-30 12:44:03 +01:00
dev/amdsbwd/amdsbwd.c optional amdsbwd
amdtemp(4): Add support for Family 17h temperature sensor The sensor value is formatted similarly to previous models (same bitfield sizes, same units), but must be read off of the internal System Management Network (SMN) from the System Management Unit (SMU) co-processor. PR: 218264 Reported and tested by: Nils Beyer <nbe AT renzel.net> Reviewed by: avg (no +1), mjoras, truckman Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12217
2017-09-05 17:19:14 +02:00
dev/amdsmn/amdsmn.c optional amdsmn | amdtemp
Rename the k8temp driver to amdtemp. MFC after: 2 weeks
2009-03-13 17:08:08 +01:00
dev/amdtemp/amdtemp.c optional amdtemp
FIx a botch with the addition of the arcmsr driver.
2005-04-01 21:32:12 +02:00
dev/arcmsr/arcmsr.c optional arcmsr pci
Connect asmc to the build infrastructure. Approved by: njl (mentor) Reviewed by: njl (mentor)
2007-11-07 21:08:15 +01:00
dev/asmc/asmc.c optional asmc isa
- Hook up the new locations of the atkbdc(4), atkbd(4) and psm(4) source files after they were repo-copied to sys/dev/atkbdc. The sources of atkbdc(4) and its children were moved to the new location in preparation for adding an EBus front-end to atkbdc(4) for use on sparc64; i.e. in order to not further scatter them over the whole tree which would have been the result of adding atkbdc_ebus.c in e.g. sys/sparc64/ebus. Another reason for the repo-copies was that some of the sources were misfiled, e.g. sys/isa/atkbd_isa.c wasn't ISA-specific at all but for hanging atkbd(4) off of atkbdc(4) and was renamed to atkbd_atkbdc.c accordingly. Most of sys/isa/psm.c, i.e. expect for its PSMC PNP part, also isn't ISA-specific. - Separate the parts of atkbdc_isa.c which aren't actually ISA-specific but are shareable between different atkbdc(4) bus front-ends into atkbdc_subr.c (repo-copied from atkbdc_isa.c). While here use bus_generic_rl_alloc_resource() and bus_generic_rl_release_resource() respectively in atkbdc_isa.c instead of rolling own versions. - Add sparc64 MD bits to atkbdc(4) and atkbd(4) and an EBus front-end for atkbdc(4). PS/2 controllers and input devices are used on a couple of Sun OEM boards and occur on either the EBus or the ISA bus. Depending on the board it's either the only on-board mean to connect a keyboard and mouse or an alternative to either RS232 or USB devices. - Wrap the PSMC PNP part of psm.c in #ifdef DEV_ISA so it can be compiled without isa(4) (e.g. for EBus-only machines). This ISA-specific part isn't separated into its own source file, yet, as it requires more work than was feasible for 6.0 in order to do it in a clean way. Actually philip@ is working on a rewrite of psm(4) so a more comprehensive clean-up and separation of hardware dependent and independent parts is expected to happen after 6.0. Tested on: i386, sparc64 (AX1105, AXe and AXi boards) Reviewed by: philip
2005-06-10 22:56:38 +02:00
dev/atkbdc/atkbd.c optional atkbd atkbdc
dev/atkbdc/atkbd_atkbdc.c optional atkbd atkbdc
dev/atkbdc/atkbdc.c optional atkbdc
dev/atkbdc/atkbdc_isa.c optional atkbdc isa
dev/atkbdc/atkbdc_subr.c optional atkbdc
dev/atkbdc/psm.c optional psm atkbdc
Substantial rewrite of bxe(4) to add support for the BCM57712 and BCM578XX controllers. Approved by: re MFC after: 4 weeks
2013-09-20 22:18:49 +02:00
dev/bxe/bxe.c optional bxe pci
dev/bxe/bxe_stats.c optional bxe pci
dev/bxe/bxe_debug.c optional bxe pci
dev/bxe/ecore_sp.c optional bxe pci
dev/bxe/bxe_elink.c optional bxe pci
dev/bxe/57710_init_values.c optional bxe pci
dev/bxe/57711_init_values.c optional bxe pci
dev/bxe/57712_init_values.c optional bxe pci
Add a driver for the on-die digital thermal sensor found on Intel Core and newer CPUs (including Core 2 and Core / Core 2 based Xeons). The driver attaches to each cpu device and creates a sysctl node in that device's sysctl context (dev.cpu.N.temperature). When invoked, the handler binds to the appropriate CPU to ensure a correct reading. Submitted by: Rui Paulo <rpaulo@fnop.net> Sponsored by: Google Summer of Code 2007 Tested by: des, marcus, Constantine A. Murenin, Ian FREISLICH Approved by: re (kensmith) MFC after: 3 weeks
2007-08-15 21:26:03 +02:00
dev/coretemp/coretemp.c optional coretemp
- Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month
2008-08-08 18:26:53 +02:00
dev/cpuctl/cpuctl.c optional cpuctl
Automatically depend on x86emu when vesa or dpms is being built into kernel. With this change the user no longer need to remember building this option. Submitted by: swell.k at gmail.com
2009-09-21 09:08:20 +02:00
dev/dpms/dpms.c optional dpms
Add the ed driver for lint building. The PCI instances are still useful. In theory, there are no isa slots on any amd64/em64t systems, but it doesn't hurt to keep these tiny fragments compiling.
2005-07-21 23:55:11 +02:00
# There are no systems with isa slots, so all ed isa entries should go..
dev/ed/if_ed_3c503.c optional ed isa ed_3c503
dev/ed/if_ed_isa.c optional ed isa
dev/ed/if_ed_wd80x3.c optional ed isa
dev/ed/if_ed_hpp.c optional ed isa ed_hpp
dev/ed/if_ed_sic.c optional ed isa ed_sic
Make config(8) understand ORed dependecies in "files*" and improve tracking of known devices. Bump config(8) version.
2005-11-27 22:41:58 +01:00
dev/fb/fb.c optional fb | vga
Enable s3pci on amd64 which works on top of VESA, and allow static building it into kernel on i386 and amd64. Submitted by: swell.k at gmail.com
2009-09-21 09:05:48 +02:00
dev/fb/s3_pci.c optional s3pci
Automatically depend on x86emu when vesa or dpms is being built into kernel. With this change the user no longer need to remember building this option. Submitted by: swell.k at gmail.com
2009-09-21 09:08:20 +02:00
dev/fb/vesa.c optional vga vesa
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 04:59:24 +02:00
dev/fb/vga.c optional vga
Sync i386->amd64. * Add ichwd (The Intel EM64T folks have an ICH) * Cosmetic comment syncs * Merge cpufreq change over to NOTES * add pbio (it compiles, but isn't useful since no boxes have ISA slots) * copy ath settings (note: wlan disabled here since its in global NOTES) * copy profiling, including fixing a previous i386->amd64 merge typo. Approved by: re (blanket i386 <-> amd64 sync/convergence)
2005-06-30 07:33:26 +02:00
dev/ichwd/ichwd.c optional ichwd
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 06:41:18 +01:00
dev/if_ndis/if_ndis.c optional ndis
dev/if_ndis/if_ndis_pccard.c optional ndis pccard
Make config(8) understand ORed dependecies in "files*" and improve tracking of known devices. Bump config(8) version.
2005-11-27 22:41:58 +01:00
dev/if_ndis/if_ndis_pci.c optional ndis cardbus | ndis pci
Throw the switch on the new driver generation/loading mechanism. From here on in, if_ndis.ko will be pre-built as a module, and can be built into a static kernel (though it's not part of GENERIC). Drivers are created using the new ndisgen(8) script, which uses ndiscvt(8) under the covers, along with a few other tools. The result is a driver module that can be kldloaded into the kernel. A driver with foo.inf and foo.sys files will be converted into foo_sys.ko (and foo_sys.o, for those who want/need to make static kernels). This module contains all of the necessary info from the .INF file and the driver binary image, converted into an ELF module. You can kldload this module (or add it to /boot/loader.conf) to have it loaded automatically. Any required firmware files can be bundled into the module as well (or converted/loaded separately). Also, add a workaround for a problem in NdisMSleep(). During system bootstrap (cold == 1), msleep() always returns 0 without actually sleeping. The Intel 2200BG driver uses NdisMSleep() to wait for the NIC's firmware to come to life, and fails to load if NdisMSleep() doesn't actually delay. As a workaround, if msleep() (and hence ndis_thsuspend()) returns 0, use a hard DELAY() to sleep instead). This is not really the right thing to do, but we can't really do much else. At the very least, this makes the Intel driver happy. There are probably other drivers that fail in this way during bootstrap. Unfortunately, the only workaround for those is to avoid pre-loading them and kldload them once the system is running instead.
2005-04-24 22:21:22 +02:00
dev/if_ndis/if_ndis_usb.c optional ndis usb
imcsmb(4): Intel integrated Memory Controller (iMC) SMBus controller driver imcsmb(4) provides smbus(4) support for the SMBus controller functionality in the integrated Memory Controllers (iMCs) embedded in Intel Sandybridge- Xeon, Ivybridge-Xeon, Haswell-Xeon, and Broadwell-Xeon CPUs. Each CPU implements one or more iMCs, depending on the number of cores; each iMC implements two SMBus controllers (iMC-SMBs). *** IMPORTANT NOTE *** Because motherboard firmware or the BMC might try to use the iMC-SMBs for monitoring DIMM temperatures and/or managing an NVDIMM, the driver might need to temporarily disable those functions, or take a hardware interlock, before using the iMC-SMBs. Details on how to do this may vary from board to board, and the procedure may be proprietary. It is strongly suggested that anyone wishing to use this driver contact their motherboard vendor, and modify the driver as described in the manual page and in the driver itself. (For what it's worth, the driver as-is has been tested on various SuperMicro motherboards.) Reviewed by: avg, jhb MFC after: 1 week Relnotes: yes Sponsored by: Panasas Differential Revision: https://reviews.freebsd.org/D14447 Discussed with: avg, ian, jhb Tested by: allanjude (previous version), Panasas
2018-03-03 02:53:51 +01:00
dev/imcsmb/imcsmb.c optional imcsmb
dev/imcsmb/imcsmb_pci.c optional imcsmb pci
[intelspi] Add SPI driver for Intel BayTrail SoC Add SPI mode (PIO-only) support for Intel Synchronous Serial Port that can be found in several Intel's products starting from PXA family. Most of implementations have slight differences in behavior and in addresses for registers subset. This driver covers only BayTrail SoC implementation for it's the only hardware I have to test it on. Driver attaches to ACPI bus only and does not have PCI or FDT support for now due to lack of hardware to test it on. "intelspi" is the best name I've managed to come up with. Linux driver name (spi-pxa2xx) does not make sense because current implementation does not support actual PXA2xx SoCs. And as far as I know there is no codename assigned to Intel SSP chip. Reviewed by: br, manu MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D8896
2016-12-27 23:37:24 +01:00
dev/intel/spi.c optional intelspi
Break out the MI part of the /dev/[k]mem and /dev/io drivers into their own directory and module, leaving the MD parts in the MD area (the MD parts _are_ part of the modules). /dev/mem and /dev/io are now loadable modules, thus taking us one step further towards a kernel created entirely out of modules. Of course, there is nothing preventing the kernel from having these statically compiled.
2004-08-01 13:40:54 +02:00
dev/io/iodev.c optional io
Import ioat(4) driver I/OAT is also referred to as Crystal Beach DMA and is a Platform Storage Extension (PSE) on some Intel server platforms. This driver currently supports DMA descriptors only and is part of a larger effort to upstream an interconnect between multiple systems using the Non-Transparent Bridge (NTB) PSE. For now, this driver is only built on AMD64 platforms. It may be ported to work on i386 later, if that is desired. The hardware is exclusive to x86. Further documentation on ioat(4), including API documentation and usage, can be found in the new manual page. Bring in a test tool, ioatcontrol(8), in tools/tools/ioat. The test tool is not hooked up to the build and is not intended for end users. Submitted by: jimharris, Carl Delsey <carl.r.delsey@intel.com> Reviewed by: jimharris (reviewed my changes) Approved by: markj (mentor) Relnotes: yes Sponsored by: Intel Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D3456
2015-08-24 21:32:03 +02:00
dev/ioat/ioat.c optional ioat pci
dev/ioat/ioat_test.c optional ioat pci
Tie the ipmi driver into the i386/amd64 builds.
2006-02-13 18:56:24 +01:00
dev/ipmi/ipmi.c optional ipmi
Update the ipmi(4) driver: - Split out the communication protocols into their own files and use a couple of function pointers in the softc that the commuication protocols setup in their own attach routine. - Add support for the SSIF interface (talking to IPMI over SMBus). - Add an ACPI attachment. - Add a PCI attachment that attaches to devices with the IPMI interface subclass. - Split the ISA attachment out into its own file: ipmi_isa.c. - Change the code to probe the SMBIOS table for an IPMI entry to just use pmap_mapbios() to map the table in rather than trying to setup a fake resource on an isa device and then activating the resource to map in the table. - Make bus attachments leaner by adding attach functions for each communication interface (ipmi_kcs_attach(), ipmi_smic_attach(), etc.) that setup per-interface data. - Formalize the model used by the driver to handle requests by adding an explicit struct ipmi_request object that holds the state of a given request and reply for the entire lifetime of the request. By bundling the request into an object, it is easier to add retry logic to the various communication backends (as well as eventually support BT mode which uses a slightly different message format than KCS, SMIC, and SSIF). - Add a per-softc lock and remove D_NEEDGIANT as the driver is now MPSAFE. - Add 32-bit compatibility ioctl shims so you can use a 32-bit ipmitool on FreeBSD/amd64. - Add ipmi(4) to i386 and amd64 NOTES. Submitted by: ambrisko (large portions of 2 and 3) Sponsored by: IronPort Systems, Yahoo! MFC after: 6 days
2006-09-23 00:11:29 +02:00
dev/ipmi/ipmi_acpi.c optional ipmi acpi
dev/ipmi/ipmi_isa.c optional ipmi isa
dev/ipmi/ipmi_kcs.c optional ipmi
dev/ipmi/ipmi_smic.c optional ipmi
dev/ipmi/ipmi_smbus.c optional ipmi smbus
dev/ipmi/ipmi_smbios.c optional ipmi
dev/ipmi/ipmi_ssif.c optional ipmi smbus
Tie the ipmi driver into the i386/amd64 builds.
2006-02-13 18:56:24 +01:00
dev/ipmi/ipmi_pci.c optional ipmi pci
Sigh, not my day. Check-in the update version that didn't have the linux_compat mistakes.
2009-03-26 21:23:21 +01:00
dev/ipmi/ipmi_linux.c optional ipmi compat_linux32
As per [1] Intel only supports this driver on 64bit platforms. For now restrict it to amd64. Other architectures might be re-added later once tested. Remove the drivers from the global NOTES and files files and move them to the amd64 specifics. Remove the drivers from the i386 modules build and only leave the amd64 version. Rather than depending on "inet" depend on "pci" and make sure that ixl(4) and ixlv(4) can be compiled independently [2]. This also allows the drivers to build properly on IPv4-only or IPv6-only kernels. PR: 193824 [2] Reviewed by: eric.joyner intel.com MFC after: 3 days References: [1] http://lists.freebsd.org/pipermail/svn-src-all/2014-August/090470.html
2014-09-23 10:33:03 +02:00
dev/ixl/if_ixl.c optional ixl pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
ixl(4): Update to ixl-1.6.6-k. Submitted by: erj Reviewed by: jeffrey.e.pieper@intel.com MFC after: 3 days Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D7391
2016-08-07 20:12:36 +02:00
dev/ixl/ixl_pf_main.c optional ixl pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
dev/ixl/ixl_pf_qmgr.c optional ixl pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
Fix kldload of if_ixl without PCI_IOV kernel option. This also avoids compiling in pci_iov support into the kernel if_ixoif the PCI_IOV option is disabled. Reviewed by: rstone Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D11573
2017-07-14 00:45:23 +02:00
dev/ixl/ixl_pf_iov.c optional ixl pci pci_iov \
ixl(4): Update to ixl-1.6.6-k. Submitted by: erj Reviewed by: jeffrey.e.pieper@intel.com MFC after: 3 days Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D7391
2016-08-07 20:12:36 +02:00
compile-with "${NORMAL_C} -I$S/dev/ixl"
ixl(4): Update to 1.7.12-k Refresh upstream driver before impending conversion to iflib. Major new features: - Support for Fortville-based 25G adapters - Support for I2C reads/writes (To prevent getting or sending corrupt data, you should set dev.ixl.0.debug.disable_fw_link_management=1 when using I2C [this will disable link!], then set it to 0 when done. The driver implements the SIOCGI2C ioctl, so ifconfig -v works for reading I2C data, but there are read_i2c and write_i2c sysctls under the .debug sysctl tree [the latter being useful for upper page support in QSFP+]). - Addition of an iWARP client interface (so the future iWARP driver for X722 devices can communicate with the base driver). - Compiling this option in is enabled by default, with "options IXL_IW" in GENERIC. Differential Revision: https://reviews.freebsd.org/D9227 Reviewed by: sbruno MFC after: 2 weeks Sponsored by: Intel Corporation
2017-02-10 02:04:11 +01:00
dev/ixl/ixl_pf_i2c.c optional ixl pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
dev/ixl/ixl_iw.c optional ixl pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
As per [1] Intel only supports this driver on 64bit platforms. For now restrict it to amd64. Other architectures might be re-added later once tested. Remove the drivers from the global NOTES and files files and move them to the amd64 specifics. Remove the drivers from the i386 modules build and only leave the amd64 version. Rather than depending on "inet" depend on "pci" and make sure that ixl(4) and ixlv(4) can be compiled independently [2]. This also allows the drivers to build properly on IPv4-only or IPv6-only kernels. PR: 193824 [2] Reviewed by: eric.joyner intel.com MFC after: 3 days References: [1] http://lists.freebsd.org/pipermail/svn-src-all/2014-August/090470.html
2014-09-23 10:33:03 +02:00
dev/ixl/if_ixlv.c optional ixlv pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
dev/ixl/ixlvc.c optional ixlv pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
dev/ixl/ixl_txrx.c optional ixl pci | ixlv pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
dev/ixl/i40e_osdep.c optional ixl pci | ixlv pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
dev/ixl/i40e_lan_hmc.c optional ixl pci | ixlv pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
dev/ixl/i40e_hmc.c optional ixl pci | ixlv pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
dev/ixl/i40e_common.c optional ixl pci | ixlv pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
dev/ixl/i40e_nvm.c optional ixl pci | ixlv pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
dev/ixl/i40e_adminq.c optional ixl pci | ixlv pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
Fix mismerge of fdc. Also, OLDCARD never was supported on amd64, so remove fdc attachment for it.
2004-07-09 07:05:13 +02:00
dev/fdc/fdc.c optional fdc
Hook up fdc_acpi for the kernel build.
2004-07-15 18:43:52 +02:00
dev/fdc/fdc_acpi.c optional fdc
Break out the isa and pccard front ends to the fdc controller device. This should allow us to more easily break out the acpi and 'legacy pc' front ends as well (so only the bus front end would touch rtc, for example). This isn't a great separation, since isa dma routines are still called from the MI code, but it is a start.
2004-07-08 00:29:33 +02:00
dev/fdc/fdc_isa.c optional fdc isa
dev/fdc/fdc_pccard.c optional fdc pccard
[gpio] Add GPIO driver for Intel Bay Trail SoC Bay Trail has three banks of GPIOs exposed to userland as /dev/gpiocN, where N is 1, 2, and 3. Pins in each bank are pre-named to match names on boards schematics: GPIO_S0_SCnn, GPIO_S0_NCnn, and GPIO_S5_nn. Controller supports edge-triggered and level-triggered interrupts but current version of the driver does not have interrupts support
2016-11-04 17:24:38 +01:00
dev/gpio/bytgpio.c optional bytgpio
[chvgpio] add GPIO driver for Intel Z8xxx SoC family Add chvgpio(4) driver for Intel Z8xxx SoC family. This product was formerly known as Cherry Trail but Linux and OpenBSD drivers refer to it as Cherry View. This driver is derived from OpenBSD one so the name is kept for alignment with another BSD system. Submitted by: Tom Jones <tj@enoti.me> Reviewed by: gonzo, wblock(man page) MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D13086
2018-02-22 20:12:32 +01:00
dev/gpio/chvgpio.c optional chvgpio
Import HighPoint DC Series Data Center HBA (DC7280 and R750) driver. This driver works for FreeBSD/i386 and FreeBSD/amd64 platforms. Many thanks to HighPoint for providing this driver. MFC after: 1 day
2013-07-06 09:49:41 +02:00
dev/hpt27xx/hpt27xx_os_bsd.c optional hpt27xx
dev/hpt27xx/hpt27xx_osm_bsd.c optional hpt27xx
Import the first release of HighPoint RocketRAID 27xx SAS 6Gb/s HBA card driver. This driver works for FreeBSD/i386 and FreeBSD/amd64 platforms. Many thanks to HighPoint for providing this driver. MFC after: 2 weeks
2011-12-29 00:26:58 +01:00
dev/hpt27xx/hpt27xx_config.c optional hpt27xx
Hook up the hptmv driver for amd64. MFC After: 3 days
2005-09-08 05:29:18 +02:00
dev/hptmv/entry.c optional hptmv
dev/hptmv/mv.c optional hptmv
dev/hptmv/gui_lib.c optional hptmv
dev/hptmv/hptproc.c optional hptmv
dev/hptmv/ioctl.c optional hptmv
Import HighPoint DC Series Data Center HBA (DC7280 and R750) driver. This driver works for FreeBSD/i386 and FreeBSD/amd64 platforms. Many thanks to HighPoint for providing this driver. MFC after: 1 day
2013-07-06 09:49:41 +02:00
dev/hptnr/hptnr_os_bsd.c optional hptnr
dev/hptnr/hptnr_osm_bsd.c optional hptnr
dev/hptnr/hptnr_config.c optional hptnr
Add the 'hptrr' driver for supporting the following Highpoint RocketRAID cards: o RocketRAID 172x series o RocketRAID 174x series o RocketRAID 2210 o RocketRAID 222x series o RocketRAID 2240 o RocketRAID 230x series o RocketRAID 231x series o RocketRAID 232x series o RocketRAID 2340 o RocketRAID 2522 Many thanks to Highpoint for their continued support of FreeBSD. Submitted by: Highpoint
2007-12-15 01:56:17 +01:00
dev/hptrr/hptrr_os_bsd.c optional hptrr
dev/hptrr/hptrr_osm_bsd.c optional hptrr
dev/hptrr/hptrr_config.c optional hptrr
Update the file.* entries for the new home of hwpmc
2005-04-29 04:40:16 +02:00
dev/hwpmc/hwpmc_amd.c optional hwpmc
- Separate PMC class dependent code from other kinds of machine dependencies. A 'struct pmc_classdep' structure describes operations on PMCs; 'struct pmc_mdep' contains one or more 'struct pmc_classdep' structures depending on the CPU in question. Inside PMC class dependent code, row indices are relative to the PMCs supported by the PMC class; MI code in "hwpmc_mod.c" translates global row indices before invoking class dependent operations. - Augment the OP_GETCPUINFO request with the number of PMCs present in a PMC class. - Move code common to Intel CPUs to file "hwpmc_intel.c". - Move TSC handling to file "hwpmc_tsc.c".
2008-11-09 18:37:54 +01:00
dev/hwpmc/hwpmc_intel.c optional hwpmc
- Add support for PMCs in Intel CPUs of Family 6, model 0xE (Core Solo and Core Duo), models 0xF (Core2), model 0x17 (Core2Extreme) and model 0x1C (Atom). In these CPUs, the actual numbers, kinds and widths of PMCs present need to queried at run time. Support for specific "architectural" events also needs to be queried at run time. Model 0xE CPUs support programmable PMCs, subsequent CPUs additionally support "fixed-function" counters. - Use event names that are close to vendor documentation, taking in account that: - events with identical semantics on two or more CPUs in this family can have differing names in vendor documentation, - identical vendor event names may map to differing events across CPUs, - each type of CPU supports a different subset of measurable events. Fixed-function and programmable counters both use the same vendor names for events. The use of a class name prefix ("iaf-" or "iap-" respectively) permits these to be distinguished. - In libpmc, refactor pmc_name_of_event() into a public interface and an internal helper function, for use by log handling code. - Minor code tweaks: staticize a global, freshen a few comments. Tested by: gnn
2008-11-27 10:00:47 +01:00
dev/hwpmc/hwpmc_core.c optional hwpmc
- Support for uncore counting events: one fixed PMC with the uncore domain clock, 8 programmable PMC. - Westmere based CPU (Xeon 5600, Corei7 980X) support. - New man pages with events list for core and uncore. - Updated Corei7 events with Intel 253669-033US December 2009 doc. There is some removed events in the documentation, they have been kept in the code but documented in the man page as obsolete. - Offcore response events can be setup with rsp token. Sponsored by: NETASQ
2010-04-02 15:23:49 +02:00
dev/hwpmc/hwpmc_uncore.c optional hwpmc
MFP4: - Implement sampling modes and logging support in hwpmc(4). - Separate MI and MD parts of hwpmc(4) and allow sharing of PMC implementations across different architectures. Add support for P4 (EMT64) style PMCs to the amd64 code. - New pmcstat(8) options: -E (exit time counts) -W (counts every context switch), -R (print log file). - pmc(3) API changes, improve our ability to keep ABI compatibility in the future. Add more 'alias' names for commonly used events. - bug fixes & documentation.
2005-06-09 21:45:09 +02:00
dev/hwpmc/hwpmc_piv.c optional hwpmc
- Separate PMC class dependent code from other kinds of machine dependencies. A 'struct pmc_classdep' structure describes operations on PMCs; 'struct pmc_mdep' contains one or more 'struct pmc_classdep' structures depending on the CPU in question. Inside PMC class dependent code, row indices are relative to the PMCs supported by the PMC class; MI code in "hwpmc_mod.c" translates global row indices before invoking class dependent operations. - Augment the OP_GETCPUINFO request with the number of PMCs present in a PMC class. - Move code common to Intel CPUs to file "hwpmc_intel.c". - Move TSC handling to file "hwpmc_tsc.c".
2008-11-09 18:37:54 +01:00
dev/hwpmc/hwpmc_tsc.c optional hwpmc
MFP4: - Implement sampling modes and logging support in hwpmc(4). - Separate MI and MD parts of hwpmc(4) and allow sharing of PMC implementations across different architectures. Add support for P4 (EMT64) style PMCs to the amd64 code. - New pmcstat(8) options: -E (exit time counts) -W (counts every context switch), -R (print log file). - pmc(3) API changes, improve our ability to keep ABI compatibility in the future. Add more 'alias' names for commonly used events. - bug fixes & documentation.
2005-06-09 21:45:09 +02:00
dev/hwpmc/hwpmc_x86.c optional hwpmc
hyperv/kbd: Add support for synthetic keyboard. Synthetic keyboard is the only supported keyboard on GEN2 Hyper-V. Submitted by: Hongjiang Zhang <honzhan microsoft com> MFC after: 1 week Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D10196
2017-04-05 07:01:23 +02:00
dev/hyperv/input/hv_kbd.c optional hyperv
dev/hyperv/input/hv_kbdc.c optional hyperv
hyperv/pcib: change the file name: pcib.c -> vmbus_pcib.c This makes the file name and the variable naming in the file consistent. Reviewed by: sephe Approved by: sephe (mentor) MFC after: 1 week Sponsored by: Microsoft
2016-11-18 07:44:18 +01:00
dev/hyperv/pcib/vmbus_pcib.c optional hyperv pci
hyperv/hn: Rename cleaned up NVS source file. MFC after: 1 week Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D8354
2016-10-28 09:48:17 +02:00
dev/hyperv/netvsc/hn_nvs.c optional hyperv
hyperv/hn: Rename cleaned up RNDIS source file. MFC after: 1 week Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D8361
2016-10-31 02:36:28 +01:00
dev/hyperv/netvsc/hn_rndis.c optional hyperv
hyperv/hn: Rename cleaned up file. MFC after: 1 week Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D8390
2016-11-01 07:54:25 +01:00
dev/hyperv/netvsc/if_hn.c optional hyperv
First cut at adding the hyperv drivers to GENERIC. The files inventory should probably have the modules split out into net/storage/common etc as the modules build is, but this will do for now.
2013-07-19 07:32:58 +02:00
dev/hyperv/storvsc/hv_storvsc_drv_freebsd.c optional hyperv
Import HyperV Key-Value Pair (KVP) driver and daemon code by Microsoft, many thanks for their continued support of FreeBSD. While I'm there, also implement a new build knob, WITHOUT_HYPERV to disable building and installing of the HyperV utilities when necessary. The HyperV utilities are only built for i386 and amd64 targets. This is a stable/10 candidate for inclusion with 10.1-RELEASE. Submitted by: Wei Hu <weh microsoft com> MFC after: 1 week
2014-09-13 04:15:31 +02:00
dev/hyperv/utilities/hv_kvp.c optional hyperv
hyperv/vss: Add driver and tools for VSS VSS stands for "Volume Shadow Copy Service". Unlike virtual machine snapshot, it only takes snapshot for the virtual disks, so both filesystem and applications have to aware of it, and cooperate the whole VSS process. This driver exposes two device files to the userland: /dev/hv_fsvss_dev Normally userland programs should _not_ mess with this device file. It is currently used by the hv_vss_daemon(8), which freezes and thaws the filesystem. NOTE: currently only UFS is supported, if the system mounts _any_ other filesystems, the hv_vss_daemon(8) will veto the VSS process. If hv_vss_daemon(8) was disabled, then this device file must be opened, and proper ioctls must be issued to keep the VSS working. /dev/hv_appvss_dev Userland application can opened this device file to receive the VSS freeze notification, hold the VSS for a while (mainly to flush application data to filesystem), release the VSS process, and receive the VSS thaw notification i.e. applications can run again. The VSS will still work, even if this device file is not opened. However, only filesystem consistency is promised, if this device file is not opened or is not operated properly. hv_vss_daemon(8) is started by devd(8) by default. It can be disabled by editting /etc/devd/hyperv.conf. Submitted by: Hongjiang Zhang <honzhan microsoft com> Reviewed by: kib, mckusick MFC after: 3 weeks Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D8224
2016-11-15 03:36:12 +01:00
dev/hyperv/utilities/hv_snapshot.c optional hyperv
hyperv/ic: Rename cleaned up files. MFC after: 1 week Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D8850
2016-12-20 10:46:14 +01:00
dev/hyperv/utilities/vmbus_heartbeat.c optional hyperv
hyperv/ic: Rname cleaned up file. MFC after: 1 week Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D8848
2016-12-20 08:14:24 +01:00
dev/hyperv/utilities/vmbus_ic.c optional hyperv
hyperv/ic: Rename cleaned up files. MFC after: 1 week Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D8850
2016-12-20 10:46:14 +01:00
dev/hyperv/utilities/vmbus_shutdown.c optional hyperv
dev/hyperv/utilities/vmbus_timesync.c optional hyperv
hyperv: Rename some cleaned up/almost cleaned up files MFC after: 1 week Sponsored by: Microsoft OSTC
2016-06-01 11:20:52 +02:00
dev/hyperv/vmbus/hyperv.c optional hyperv
hyperv: Add helpers for busdma(9) operation MFC after: 1 week Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D6443
2016-05-23 08:35:11 +02:00
dev/hyperv/vmbus/hyperv_busdma.c optional hyperv
hyperv/pcib: Fix the build for some kernel configs Add the dependency on pci explicitly for the pcib and vmbus drivers. The related Makefiles are updated accordingly too. Reviewed by: sephe Approved by: sephe (mentor) MFC after: 1 week Sponsored by: Microsoft
2016-11-18 06:33:01 +01:00
dev/hyperv/vmbus/vmbus.c optional hyperv pci
hyperv/vmbus: Rename cleaned up bufring code MFC after: 1 week Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D7318
2016-07-27 11:27:08 +02:00
dev/hyperv/vmbus/vmbus_br.c optional hyperv
hyperv/vmbus: Rename laundered vmbus channel code MFC after: 1 week Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D7232
2016-07-19 09:51:22 +02:00
dev/hyperv/vmbus/vmbus_chan.c optional hyperv
hyperv: Rename some cleaned up/almost cleaned up files MFC after: 1 week Sponsored by: Microsoft OSTC
2016-06-01 11:20:52 +02:00
dev/hyperv/vmbus/vmbus_et.c optional hyperv
hyperv/vmbus: Rework vmbus version accessing. Instead of global variable, vmbus version is accessed through a vmbus DEVMETHOD now. MFC after: 1 week Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D6953
2016-07-12 09:33:39 +02:00
dev/hyperv/vmbus/vmbus_if.m optional hyperv
hyperv/vmbus: Reorganize vmbus device tree For GEN1 Hyper-V, vmbus is attached to pcib0, which contains the resources for PCI passthrough and SR-IOV. There is no acpi_syscontainer0 on GEN1 Hyper-V. For GEN2 Hyper-V, vmbus is attached to acpi_syscontainer0, which contains the resources for PCI passthrough and SR-IOV. There is no pcib0 on GEN2 Hyper-V. The ACPI VMBUS device now only holds its _CRS, which is empty as of this commit; its existence is mainly for upward compatibility. Device tree structure is suggested by jhb@. Tested-by: dexuan@ Collabrated-wth: dexuan@ MFC after: 1 week Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D10565
2017-05-10 07:28:14 +02:00
dev/hyperv/vmbus/vmbus_res.c optional hyperv
hyperv/vmbus: Add APIs for various types of transactions. Reviewed by: Jun Su <junsu microsoft com> MFC after: 1 week Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D7456
2016-08-11 07:49:49 +02:00
dev/hyperv/vmbus/vmbus_xact.c optional hyperv
hyperv: Move machine dependent bits into machine dependent files. MFC after: 1 week Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D6701
2016-06-06 07:55:37 +02:00
dev/hyperv/vmbus/amd64/hyperv_machdep.c optional hyperv
hyperv: Rename some cleaned up/almost cleaned up files MFC after: 1 week Sponsored by: Microsoft OSTC
2016-06-01 11:20:52 +02:00
dev/hyperv/vmbus/amd64/vmbus_vector.S optional hyperv
Add nctgpio conf lines so it can be compiled into the kernel. MFC after: 2 days
2017-03-30 17:05:10 +02:00
dev/nctgpio/nctgpio.c optional nctgpio
Add a pure open source nForce Ethernet driver, under BSDL. This driver was ported from OpenBSD by Shigeaki Tagashira <shigeaki@se.hiroshima-u.ac.jp> and posted at http://www.se.hiroshima-u.ac.jp/~shigeaki/software/freebsd-nfe.html It was additionally cleaned up by me. It is still a work-in-progress and thus is purposefully not in GENERIC. And it conflicts with nve(4), so only one should be loaded.
2006-06-27 01:41:07 +02:00
dev/nfe/if_nfe.c optional nfe pci
Add a new driver to support the Intel Non-Transparent Bridge(NTB). The NTB allows you to connect two systems with this device using a PCI-e link. The driver is made of two modules: - ntb_hw which is a basic hardware abstraction layer for the device. - if_ntb which implements the ntb network device and the communication protocol. The driver is limited at the moment to CPU memcpy instead of using DMA, and only Back-to-Back mode is supported. Also the network device isn't full featured yet. These changes will be coming soon. The DMA change will also bring in the ioat driver from the project branch it is on now. This is an initial port of the GPL/BSD Linux driver contributed by Jon Mason from Intel. Any bugs are my contributions. Sponsored by: Intel Reviewed by: jimharris, joel (man page only) Approved by: jimharris (mentor)
2013-04-30 00:48:53 +02:00
dev/ntb/if_ntb/if_ntb.c optional if_ntb
Add NTB driver for PLX/Avago/Broadcom PCIe switches. This driver supports both NTB-to-NTB and NTB-to-Root Port modes (though the second with predictable complications on hot-plug and reboot events). I tested it with PEX 8717 and PEX 8733 chips, but expect it should work with many other compatible ones too. It supports up to two NT bridges per chip, each of which can have up to 2 64-bit or 4 32-bit memory windows, 6 or 12 scratchpad registers and 16 doorbells. There are also 4 DMA engines in those chips, but they are not yet supported. While there, rename Intel NTB driver from generic ntb_hw(4) to more specific ntb_hw_intel(4), so now it is on par with this new ntb_hw_plx(4) driver and alike to Linux naming. MFC after: 2 weeks Sponsored by: iXsystems, Inc.
2017-08-30 23:16:32 +02:00
dev/ntb/ntb_transport.c optional ntb_transport | if_ntb
dev/ntb/ntb.c optional ntb | ntb_transport | if_ntb | ntb_hw_intel | ntb_hw_plx | ntb_hw
dev/ntb/ntb_if.m optional ntb | ntb_transport | if_ntb | ntb_hw_intel | ntb_hw_plx | ntb_hw
dev/ntb/ntb_hw/ntb_hw_intel.c optional ntb_hw_intel | ntb_hw
dev/ntb/ntb_hw/ntb_hw_plx.c optional ntb_hw_plx | ntb_hw
Integrate nvme(4) and nvd(4) into the amd64 and i386 builds. Sponsored by: Intel
2012-09-17 21:26:33 +02:00
dev/nvd/nvd.c optional nvd nvme
dev/nvme/nvme.c optional nvme
dev/nvme/nvme_ctrlr.c optional nvme
dev/nvme/nvme_ctrlr_cmd.c optional nvme
dev/nvme/nvme_ns.c optional nvme
dev/nvme/nvme_ns_cmd.c optional nvme
dev/nvme/nvme_qpair.c optional nvme
Make nvd vs nda choice boot-time rather than build-time Introduce hw.nvme.use_nvd tunable. This tunable allows both nvd and nda to be installed in the kernel, while allowing only one of them to create devices. This is an all-or-nothing setting, and you can't change it after boot-time. However, it will allow easier A/B testing. Differential Revision: https://reviews.freebsd.org/D11825
2017-08-04 05:40:01 +02:00
dev/nvme/nvme_sim.c optional nvme scbus
Integrate nvme(4) and nvd(4) into the amd64 and i386 builds. Sponsored by: Intel
2012-09-17 21:26:33 +02:00
dev/nvme/nvme_sysctl.c optional nvme
dev/nvme/nvme_test.c optional nvme
Add message when nvd disks are attached and detached. As part of this commit, add an nvme_strvis() function which borrows heavily from cam_strvis(). This will allow stripping of leading/trailing whitespace and also handle unprintable characters in model/serial numbers. This function goes into a new nvme_util.c file which is used by both the driver and nvmecontrol. Sponsored by: Intel Reviewed by: carl MFC after: 3 days
2013-07-19 23:40:57 +02:00
dev/nvme/nvme_util.c optional nvme
Split /dev/nvram driver out of isa/clock.c for i386 and amd64. I have not refactored it to be a generic device. Instead of being part of the standard kernel, there is now a 'nvram' device for i386/amd64. It is in DEFAULTS like io and mem, and can be turned off with 'nodevice nvram'. This matches the previous behavior when it was first committed.
2007-10-26 05:23:54 +02:00
dev/nvram/nvram.c optional nvram isa
Snapshot. Looking pretty good; this mostly works now. New code includes: * Read cached entropy at startup, both from files and from loader(8) preloaded entropy. Failures are soft, but announced. Untested. * Use EVENTHANDLER to do above just before we go multiuser. Untested.
2013-10-07 00:45:02 +02:00
dev/random/ivy.c optional rdrand_rng
dev/random/nehemiah.c optional padlock_rng
Add Qlogic 10Gb Ethernet Driver for Qlogic 8100 Series CNA Adapter Driver version (v2.0.0) Submitted by: David C Somayajulu (davidcs@freebsd.org) QLogic Corporation Approved by: George Neville-Neil (gnn@freebsd.org)
2013-06-25 19:50:22 +02:00
dev/qlxge/qls_dbg.c optional qlxge pci
dev/qlxge/qls_dump.c optional qlxge pci
dev/qlxge/qls_hw.c optional qlxge pci
dev/qlxge/qls_ioctl.c optional qlxge pci
dev/qlxge/qls_isr.c optional qlxge pci
dev/qlxge/qls_os.c optional qlxge pci
Add QLogic 10 Gigabit Ethernet & CNA Adapter Driver version 1.30 for 3200 and 8200 series cards. Submitted by: David C Somayajulu (david.somayajulu@qlogic.com), Qlogic Corporation MFC After: 3 days
2011-11-03 22:20:22 +01:00
dev/qlxgb/qla_dbg.c optional qlxgb pci
dev/qlxgb/qla_hw.c optional qlxgb pci
dev/qlxgb/qla_ioctl.c optional qlxgb pci
dev/qlxgb/qla_isr.c optional qlxgb pci
dev/qlxgb/qla_misc.c optional qlxgb pci
dev/qlxgb/qla_os.c optional qlxgb pci
Add Qlogic 10Gigabit Ethernet & CNA Adapter Driver Version 3.10.10 for QLogic 8300 Series Adapters Submitted by: David C Somayajulu (davidcs@freebsd.org) QLogic Corporation Approved by: George Neville-Neil (gnn@freebsd.org)
2013-05-15 19:03:09 +02:00
dev/qlxgbe/ql_dbg.c optional qlxgbe pci
dev/qlxgbe/ql_hw.c optional qlxgbe pci
dev/qlxgbe/ql_ioctl.c optional qlxgbe pci
dev/qlxgbe/ql_isr.c optional qlxgbe pci
dev/qlxgbe/ql_misc.c optional qlxgbe pci
dev/qlxgbe/ql_os.c optional qlxgbe pci
dev/qlxgbe/ql_reset.c optional qlxgbe pci
Cleanup the bitmap_xxx() functions in the LinuxKPI: - Move all bitmap related functions from bitops.h to bitmap.h, similar to what Linux does. - Apply some minor code cleanup and simplifications to optimize the generated code when using static inline functions. - Implement the following list of bitmap functions which are needed by drm-next and ibcore: - bitmap_find_next_zero_area_off() - bitmap_find_next_zero_area() - bitmap_or() - bitmap_and() - bitmap_xor() - Add missing include directives to the qlnxe driver (davidcs@ has been notified) MFC after: 1 week Sponsored by: Mellanox Technologies
2017-04-06 15:30:31 +02:00
dev/qlnx/qlnxe/ecore_cxt.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_dbg_fw_funcs.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_dcbx.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_dev.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_hw.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_init_fw_funcs.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_init_ops.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_int.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_l2.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_mcp.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_sp_commands.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_spq.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/qlnx_ioctl.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/qlnx_os.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
Update file list for sfgxe(4) again and hey, my amd64 kernels compile again.
2016-05-14 10:55:15 +02:00
dev/sfxge/common/ef10_ev.c optional sfxge pci
dev/sfxge/common/ef10_filter.c optional sfxge pci
dev/sfxge/common/ef10_intr.c optional sfxge pci
dev/sfxge/common/ef10_mac.c optional sfxge pci
dev/sfxge/common/ef10_mcdi.c optional sfxge pci
dev/sfxge/common/ef10_nic.c optional sfxge pci
dev/sfxge/common/ef10_nvram.c optional sfxge pci
dev/sfxge/common/ef10_phy.c optional sfxge pci
dev/sfxge/common/ef10_rx.c optional sfxge pci
dev/sfxge/common/ef10_tx.c optional sfxge pci
dev/sfxge/common/ef10_vpd.c optional sfxge pci
sfxge: add 7xxx NICs family support Support 7xxx adapters including firmware-assisted TSO and VLAN tagging: - Solarflare Flareon Ultra 7000 series 10/40G adapters: - Solarflare SFN7042Q QSFP+ Server Adapter - Solarflare SFN7142Q QSFP+ Server Adapter - Solarflare Flareon Ultra 7000 series 10G adapters: - Solarflare SFN7022F SFP+ Server Adapter - Solarflare SFN7122F SFP+ Server Adapter - Solarflare SFN7322F Precision Time Synchronization Server Adapter - Solarflare Flareon 7000 series 10G adapters: - Solarflare SFN7002F SFP+ Server Adapter Support utilities to configure adapters and update firmware. The work is done by Solarflare developers (Andy Moreton, Andrew Lee and many others), Artem V. Andreev <Artem.Andreev at oktetlabs.ru> and me. Sponsored by: Solarflare Communications, Inc. MFC after: 2 weeks Causually read by: gnn Differential Revision: https://reviews.freebsd.org/D2618
2015-05-25 10:34:55 +02:00
dev/sfxge/common/efx_bootcfg.c optional sfxge pci
dev/sfxge/common/efx_crc32.c optional sfxge pci
dev/sfxge/common/efx_ev.c optional sfxge pci
dev/sfxge/common/efx_filter.c optional sfxge pci
dev/sfxge/common/efx_hash.c optional sfxge pci
dev/sfxge/common/efx_intr.c optional sfxge pci
sfxge: add accessors for license-related MCDI calls to common code Add support for Huntington MCDI licensing interface to common code. Ported from Linux net driver IOCTL functions with restructuring for initial support for V3 licensing API. Submitted by: Richard Houldsworth <rhouldsworth at solarflare.com> Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4918
2016-01-14 10:19:28 +01:00
dev/sfxge/common/efx_lic.c optional sfxge pci
sfxge: add 7xxx NICs family support Support 7xxx adapters including firmware-assisted TSO and VLAN tagging: - Solarflare Flareon Ultra 7000 series 10/40G adapters: - Solarflare SFN7042Q QSFP+ Server Adapter - Solarflare SFN7142Q QSFP+ Server Adapter - Solarflare Flareon Ultra 7000 series 10G adapters: - Solarflare SFN7022F SFP+ Server Adapter - Solarflare SFN7122F SFP+ Server Adapter - Solarflare SFN7322F Precision Time Synchronization Server Adapter - Solarflare Flareon 7000 series 10G adapters: - Solarflare SFN7002F SFP+ Server Adapter Support utilities to configure adapters and update firmware. The work is done by Solarflare developers (Andy Moreton, Andrew Lee and many others), Artem V. Andreev <Artem.Andreev at oktetlabs.ru> and me. Sponsored by: Solarflare Communications, Inc. MFC after: 2 weeks Causually read by: gnn Differential Revision: https://reviews.freebsd.org/D2618
2015-05-25 10:34:55 +02:00
dev/sfxge/common/efx_mac.c optional sfxge pci
dev/sfxge/common/efx_mcdi.c optional sfxge pci
dev/sfxge/common/efx_mon.c optional sfxge pci
dev/sfxge/common/efx_nic.c optional sfxge pci
dev/sfxge/common/efx_nvram.c optional sfxge pci
dev/sfxge/common/efx_phy.c optional sfxge pci
dev/sfxge/common/efx_port.c optional sfxge pci
dev/sfxge/common/efx_rx.c optional sfxge pci
dev/sfxge/common/efx_sram.c optional sfxge pci
dev/sfxge/common/efx_tx.c optional sfxge pci
dev/sfxge/common/efx_vpd.c optional sfxge pci
dev/sfxge/common/hunt_nic.c optional sfxge pci
Update file list for sfgxe(4) again and hey, my amd64 kernels compile again.
2016-05-14 10:55:15 +02:00
dev/sfxge/common/mcdi_mon.c optional sfxge pci
dev/sfxge/common/medford_nic.c optional sfxge pci
sfxge: add 7xxx NICs family support Support 7xxx adapters including firmware-assisted TSO and VLAN tagging: - Solarflare Flareon Ultra 7000 series 10/40G adapters: - Solarflare SFN7042Q QSFP+ Server Adapter - Solarflare SFN7142Q QSFP+ Server Adapter - Solarflare Flareon Ultra 7000 series 10G adapters: - Solarflare SFN7022F SFP+ Server Adapter - Solarflare SFN7122F SFP+ Server Adapter - Solarflare SFN7322F Precision Time Synchronization Server Adapter - Solarflare Flareon 7000 series 10G adapters: - Solarflare SFN7002F SFP+ Server Adapter Support utilities to configure adapters and update firmware. The work is done by Solarflare developers (Andy Moreton, Andrew Lee and many others), Artem V. Andreev <Artem.Andreev at oktetlabs.ru> and me. Sponsored by: Solarflare Communications, Inc. MFC after: 2 weeks Causually read by: gnn Differential Revision: https://reviews.freebsd.org/D2618
2015-05-25 10:34:55 +02:00
dev/sfxge/common/siena_mac.c optional sfxge pci
dev/sfxge/common/siena_mcdi.c optional sfxge pci
dev/sfxge/common/siena_nic.c optional sfxge pci
dev/sfxge/common/siena_nvram.c optional sfxge pci
dev/sfxge/common/siena_phy.c optional sfxge pci
dev/sfxge/common/siena_sram.c optional sfxge pci
dev/sfxge/common/siena_vpd.c optional sfxge pci
dev/sfxge/sfxge.c optional sfxge pci
dev/sfxge/sfxge_dma.c optional sfxge pci
dev/sfxge/sfxge_ev.c optional sfxge pci
dev/sfxge/sfxge_intr.c optional sfxge pci
dev/sfxge/sfxge_mcdi.c optional sfxge pci
dev/sfxge/sfxge_nvram.c optional sfxge pci
dev/sfxge/sfxge_port.c optional sfxge pci
dev/sfxge/sfxge_rx.c optional sfxge pci
dev/sfxge/sfxge_tx.c optional sfxge pci
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 09:58:16 +01:00
dev/sio/sio.c optional sio
dev/sio/sio_isa.c optional sio isa
Remove sio(4) and related options from MI files to amd64, i386 and pc98 MD files. Remove nodevice and nooption lines specific to sio(4) from ia64, powerpc and sparc64 NOTES. There were no such lines for arm yet. sio(4) is usable on less than half the platforms, not counting a future mips platform. Its presence in MI files is therefore increasingly becoming a burden.
2006-07-29 20:38:54 +02:00
dev/sio/sio_pccard.c optional sio pccard
dev/sio/sio_pci.c optional sio pci
dev/sio/sio_puc.c optional sio puc
martpqi(4): - Microsemi SCSI driver for PQI controllers. - Found on newer model HP servers. - Restrict to AMD64 only as per developer request. The driver provides support for the new generation of PQI controllers from Microsemi. This driver is the first SCSI driver to implement the PQI queuing model and it will replace the aacraid driver for Adaptec Series 9 controllers. HARDWARE Controllers supported by the driver include: HPE Gen10 Smart Array Controller Family OEM Controllers based on the Microsemi Chipset. Submitted by: deepak.ukey@microsemi.com Relnotes: yes Sponsored by: Microsemi Differential Revision: https://reviews.freebsd.org/D14514
2018-04-26 18:59:06 +02:00
dev/smartpqi/smartpqi_cam.c optional smartpqi
dev/smartpqi/smartpqi_cmd.c optional smartpqi
dev/smartpqi/smartpqi_discovery.c optional smartpqi
dev/smartpqi/smartpqi_event.c optional smartpqi
dev/smartpqi/smartpqi_helper.c optional smartpqi
dev/smartpqi/smartpqi_init.c optional smartpqi
dev/smartpqi/smartpqi_intr.c optional smartpqi
dev/smartpqi/smartpqi_ioctl.c optional smartpqi
dev/smartpqi/smartpqi_main.c optional smartpqi
dev/smartpqi/smartpqi_mem.c optional smartpqi
dev/smartpqi/smartpqi_misc.c optional smartpqi
dev/smartpqi/smartpqi_queue.c optional smartpqi
dev/smartpqi/smartpqi_request.c optional smartpqi
dev/smartpqi/smartpqi_response.c optional smartpqi
dev/smartpqi/smartpqi_sis.c optional smartpqi
dev/smartpqi/smartpqi_tag.c optional smartpqi
Add /dev/speaker support to amd64. The following repo-copies were made (by Mark Murray): sys/i386/isa/spkr.c -> sys/dev/speaker/spkr.c sys/i386/include/speaker.h -> sys/dev/speaker/speaker.h share/man/man4/man4.i386/spkr.4 -> share/man/man4/spkr.4
2005-11-11 10:57:32 +01:00
dev/speaker/spkr.c optional speaker
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 09:58:16 +01:00
dev/syscons/apm/apm_saver.c optional apm_saver apm
Replace syscons terminal renderer by a new renderer that uses libteken. Some time ago I started working on a library called libteken, which is terminal emulator. It does not buffer any screen contents, but only keeps terminal state, such as cursor position, attributes, etc. It should implement all escape sequences that are implemented by the cons25 terminal emulator, but also a fair amount of sequences that are present in VT100 and xterm. A lot of random notes, which could be of interest to users/developers: - Even though I'm leaving the terminal type set to `cons25', users can do experiments with placing `xterm-color' in /etc/ttys. Because we only implement a subset of features of xterm, this may cause artifacts. We should consider extending libteken, because in my opinion xterm is the way to go. Some missing features: - Keypad application mode (DECKPAM) - Character sets (SCS) - libteken is filled with a fair amount of assertions, but unfortunately we cannot go into the debugger anymore if we fail them. I've done development of this library almost entirely in userspace. In sys/dev/syscons/teken there are two applications that can be helpful when debugging the code: - teken_demo: a terminal emulator that can be started from a regular xterm that emulates a terminal using libteken. This application can be very useful to debug any rendering issues. - teken_stress: a stress testing application that emulates random terminal output. libteken has literally survived multiple terabytes of random input. - libteken also includes support for UTF-8, but unfortunately our input layer and font renderer don't support this. If users want to experiment with UTF-8 support, they can enable `TEKEN_UTF8' in teken.h. If you recompile your kernel or the teken_demo application, you can hold some nice experiments. - I've left PC98 the way it is right now. The PC98 platform has a custom syscons renderer, which supports some form of localised input. Maybe we should port PC98 to libteken by the time syscons supports UTF-8? - I've removed the `dumb' terminal emulator. It has been broken for years. It hasn't survived the `struct proc' -> `struct thread' conversion. - To prevent confusion among people that want to hack on libteken: unlike syscons, the state machines that parse the escape sequences are machine generated. This means that if you want to add new escape sequences, you have to add an entry to the `sequences' file. This will cause new entries to be added to `teken_state.h'. - Any rendering artifacts that didn't occur prior to this commit are by accident. They should be reported to me, so I can fix them. Discussed on: current@, hackers@ Discussed with: philip (at 25C3)
2009-01-01 14:26:53 +01:00
dev/syscons/scterm-teken.c optional sc
Automatically depend on x86emu when vesa or dpms is being built into kernel. With this change the user no longer need to remember building this option. Submitted by: swell.k at gmail.com
2009-09-21 09:08:20 +02:00
dev/syscons/scvesactl.c optional sc vga vesa
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 04:59:24 +02:00
dev/syscons/scvgarndr.c optional sc vga
dev/syscons/scvtb.c optional sc
Add support 'device tpm' for amd64. Add tpm(4)'s default setting to /boot/defaults/loader.conf. Add 'device tpm' to NOTES for amd64 and i386. Discussed with: takawata Approved by: imp (mentor)
2010-09-19 16:40:37 +02:00
dev/tpm/tpm.c optional tpm
dev/tpm/tpm_acpi.c optional tpm acpi
dev/tpm/tpm_isa.c optional tpm isa
uart_cpu_amd64.c and uart_cpu_i386.c (under sys/dev/uart) are identical now that the bus spaces are unified under sys/x86. Replace them with a single uart_cpu_x86.c. o delete uart_cpu_i386.c o move uart_cpu_amd64.c to uart_cpu_x86.c o update files.amd64 and files.i386 accordingly.
2012-04-11 04:42:01 +02:00
dev/uart/uart_cpu_x86.c optional uart
Add watchdog support for VIA south bridge chipset. Tested on VT8251, VX900 but CX700, VX800, VX855 should works. MFC after: 1 month Sponsored by: NETASQ
2011-12-12 10:50:33 +01:00
dev/viawd/viawd.c optional viawd
Add vmx(4), a VMware VMXNET3 ethernet driver ported from OpenBSD
2013-08-23 22:47:16 +02:00
dev/vmware/vmxnet3/if_vmx.c optional vmx
Add VMCI (Virtual Machine Communication Interface) driver In a virtual machine, VMCI is exposed as a regular PCI device. The primary communication mechanisms supported are a point-to-point bidirectional transport based on a pair of memory-mapped queues, and asynchronous notifications in the form of datagrams and doorbells. These features are available to kernel level components such as vSockets through the VMCI kernel API. In addition to this, the VMCI kernel API provides support for receiving events related to the state of the VMCI communication channels, and the virtual machine itself. Submitted by: Vishnu Dasa <vdasa@vmware.com> Reviewed by: bcr, imp Obtained from: VMware Differential Revision: https://reviews.freebsd.org/D14289
2018-03-25 01:57:00 +01:00
dev/vmware/vmci/vmci.c optional vmci
dev/vmware/vmci/vmci_datagram.c optional vmci
dev/vmware/vmci/vmci_doorbell.c optional vmci
dev/vmware/vmci/vmci_driver.c optional vmci
dev/vmware/vmci/vmci_event.c optional vmci
dev/vmware/vmci/vmci_hashtable.c optional vmci
dev/vmware/vmci/vmci_kernel_if.c optional vmci
dev/vmware/vmci/vmci_qpair.c optional vmci
dev/vmware/vmci/vmci_queue_pair.c optional vmci
dev/vmware/vmci/vmci_resource.c optional vmci
Provide wbwd(4), a driver for the watchdog timer found on various Winbond Super I/O chips. With minor efforts it should be possible the extend the driver to support further chips/revisions available from Winbond. In the simplest case only new IDs need to be added, while different chipsets might require their own function to enter extended function mode, etc. Sponsored by: Sandvine Incorporated ULC (in 2011) Reviewed by: emaste, brueffer MFC after: 2 weeks
2012-03-06 19:44:52 +01:00
dev/wbwd/wbwd.c optional wbwd
xen: create a new PCI bus override When running as a Xen PVH Dom0 we need to add custom buses that override some of the functionality present in the ACPI PCI Bus and the PCI Bus. We currently override the ACPI PCI Bus, but not the PCI Bus, so add a new override for the PCI Bus and share the generic functions between them. Reported by: David P. Discher <dpd@dpdtech.com> Sponsored by: Citrix Systems R&D conf/files.amd64: - Add the new files. x86/xen/xen_pci_bus.c: - Generic file that contains the PCI overrides so they can be used by the several PCI specific buses. xen/xen_pci.h: - Prototypes for the generic overried functions. dev/xen/pci/xen_pci.c: - Xen specific override for the PCI bus. dev/xen/pci/xen_acpi_pci.c: - Xen specific override for the ACPI PCI bus.
2014-12-09 19:03:25 +01:00
dev/xen/pci/xen_acpi_pci.c optional xenhvm
dev/xen/pci/xen_pci.c optional xenhvm
Add isci(4) driver for amd64 and i386 targets. The isci driver is for the integrated SAS controller in the Intel C600 (Patsburg) chipset. Source files in sys/dev/isci directory are FreeBSD-specific, and sys/dev/isci/scil subdirectory contains an OS-agnostic library (SCIL) published by Intel to control the SAS controller. This library is used primarily as-is in this driver, with some post-processing to better integrate into the kernel build environment. isci.4 and a README in the sys/dev/isci directory contain a few additional details. This driver is only built for amd64 and i386 targets. Sponsored by: Intel Reviewed by: scottl Approved by: scottl
2012-01-31 20:38:18 +01:00
dev/isci/isci.c optional isci
dev/isci/isci_controller.c optional isci
dev/isci/isci_domain.c optional isci
dev/isci/isci_interrupt.c optional isci
dev/isci/isci_io_request.c optional isci
dev/isci/isci_logger.c optional isci
dev/isci/isci_oem_parameters.c optional isci
dev/isci/isci_remote_device.c optional isci
dev/isci/isci_sysctl.c optional isci
dev/isci/isci_task_request.c optional isci
dev/isci/isci_timer.c optional isci
dev/isci/scil/sati.c optional isci
dev/isci/scil/sati_abort_task_set.c optional isci
dev/isci/scil/sati_atapi.c optional isci
dev/isci/scil/sati_device.c optional isci
dev/isci/scil/sati_inquiry.c optional isci
dev/isci/scil/sati_log_sense.c optional isci
dev/isci/scil/sati_lun_reset.c optional isci
dev/isci/scil/sati_mode_pages.c optional isci
dev/isci/scil/sati_mode_select.c optional isci
dev/isci/scil/sati_mode_sense.c optional isci
dev/isci/scil/sati_mode_sense_10.c optional isci
dev/isci/scil/sati_mode_sense_6.c optional isci
dev/isci/scil/sati_move.c optional isci
dev/isci/scil/sati_passthrough.c optional isci
dev/isci/scil/sati_read.c optional isci
dev/isci/scil/sati_read_buffer.c optional isci
dev/isci/scil/sati_read_capacity.c optional isci
dev/isci/scil/sati_reassign_blocks.c optional isci
dev/isci/scil/sati_report_luns.c optional isci
dev/isci/scil/sati_request_sense.c optional isci
dev/isci/scil/sati_start_stop_unit.c optional isci
dev/isci/scil/sati_synchronize_cache.c optional isci
dev/isci/scil/sati_test_unit_ready.c optional isci
dev/isci/scil/sati_unmap.c optional isci
dev/isci/scil/sati_util.c optional isci
dev/isci/scil/sati_verify.c optional isci
dev/isci/scil/sati_write.c optional isci
dev/isci/scil/sati_write_and_verify.c optional isci
dev/isci/scil/sati_write_buffer.c optional isci
dev/isci/scil/sati_write_long.c optional isci
dev/isci/scil/sci_abstract_list.c optional isci
dev/isci/scil/sci_base_controller.c optional isci
dev/isci/scil/sci_base_domain.c optional isci
dev/isci/scil/sci_base_iterator.c optional isci
dev/isci/scil/sci_base_library.c optional isci
dev/isci/scil/sci_base_logger.c optional isci
dev/isci/scil/sci_base_memory_descriptor_list.c optional isci
dev/isci/scil/sci_base_memory_descriptor_list_decorator.c optional isci
dev/isci/scil/sci_base_object.c optional isci
dev/isci/scil/sci_base_observer.c optional isci
dev/isci/scil/sci_base_phy.c optional isci
dev/isci/scil/sci_base_port.c optional isci
dev/isci/scil/sci_base_remote_device.c optional isci
dev/isci/scil/sci_base_request.c optional isci
dev/isci/scil/sci_base_state_machine.c optional isci
dev/isci/scil/sci_base_state_machine_logger.c optional isci
dev/isci/scil/sci_base_state_machine_observer.c optional isci
dev/isci/scil/sci_base_subject.c optional isci
dev/isci/scil/sci_util.c optional isci
dev/isci/scil/scic_sds_controller.c optional isci
dev/isci/scil/scic_sds_library.c optional isci
dev/isci/scil/scic_sds_pci.c optional isci
dev/isci/scil/scic_sds_phy.c optional isci
dev/isci/scil/scic_sds_port.c optional isci
dev/isci/scil/scic_sds_port_configuration_agent.c optional isci
dev/isci/scil/scic_sds_remote_device.c optional isci
dev/isci/scil/scic_sds_remote_node_context.c optional isci
dev/isci/scil/scic_sds_remote_node_table.c optional isci
dev/isci/scil/scic_sds_request.c optional isci
dev/isci/scil/scic_sds_sgpio.c optional isci
dev/isci/scil/scic_sds_smp_remote_device.c optional isci
dev/isci/scil/scic_sds_smp_request.c optional isci
dev/isci/scil/scic_sds_ssp_request.c optional isci
dev/isci/scil/scic_sds_stp_packet_request.c optional isci
dev/isci/scil/scic_sds_stp_remote_device.c optional isci
dev/isci/scil/scic_sds_stp_request.c optional isci
dev/isci/scil/scic_sds_unsolicited_frame_control.c optional isci
dev/isci/scil/scif_sas_controller.c optional isci
dev/isci/scil/scif_sas_controller_state_handlers.c optional isci
dev/isci/scil/scif_sas_controller_states.c optional isci
dev/isci/scil/scif_sas_domain.c optional isci
dev/isci/scil/scif_sas_domain_state_handlers.c optional isci
dev/isci/scil/scif_sas_domain_states.c optional isci
dev/isci/scil/scif_sas_high_priority_request_queue.c optional isci
dev/isci/scil/scif_sas_internal_io_request.c optional isci
dev/isci/scil/scif_sas_io_request.c optional isci
dev/isci/scil/scif_sas_io_request_state_handlers.c optional isci
dev/isci/scil/scif_sas_io_request_states.c optional isci
dev/isci/scil/scif_sas_library.c optional isci
dev/isci/scil/scif_sas_remote_device.c optional isci
dev/isci/scil/scif_sas_remote_device_ready_substate_handlers.c optional isci
dev/isci/scil/scif_sas_remote_device_ready_substates.c optional isci
dev/isci/scil/scif_sas_remote_device_starting_substate_handlers.c optional isci
dev/isci/scil/scif_sas_remote_device_starting_substates.c optional isci
dev/isci/scil/scif_sas_remote_device_state_handlers.c optional isci
dev/isci/scil/scif_sas_remote_device_states.c optional isci
dev/isci/scil/scif_sas_request.c optional isci
dev/isci/scil/scif_sas_smp_activity_clear_affiliation.c optional isci
dev/isci/scil/scif_sas_smp_io_request.c optional isci
dev/isci/scil/scif_sas_smp_phy.c optional isci
dev/isci/scil/scif_sas_smp_remote_device.c optional isci
dev/isci/scil/scif_sas_stp_io_request.c optional isci
dev/isci/scil/scif_sas_stp_remote_device.c optional isci
dev/isci/scil/scif_sas_stp_task_request.c optional isci
dev/isci/scil/scif_sas_task_request.c optional isci
dev/isci/scil/scif_sas_task_request_state_handlers.c optional isci
dev/isci/scil/scif_sas_task_request_states.c optional isci
dev/isci/scil/scif_sas_timer.c optional isci
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 04:59:24 +02:00
isa/syscons_isa.c optional sc
isa/vga_isa.c optional vga
Rename timeevents.c to kern_clocksource.c. Suggested by: jhb@
2010-07-14 20:43:27 +02:00
kern/kern_clocksource.c standard
Enable first part of kld's on amd64. This is known to not work right yet, but building kld's is OK now and they can be loaded by kldload(2). (but the machine will likely crash soon afterwards, a "minor" problem :-) Brought to you by: my injured knee (from moving)
2004-05-16 22:11:38 +02:00
kern/link_elf_obj.c standard
Use inline asm instead of unportable intrinsics for the SSE4 crc32 optimization. This fixes building with gcc-4.2.1 (it doesn't support SSE4). gas-2.17.50 [FreeBSD] supports SSE4 instructions, so this doesn't need using .byte directives. This fixes depending on host user headers in the kernel. Fix user includes (don't depend on namespace pollution in <nmmintrin.h> that is not included now). The instrinsics had no advantages except to sometimes avoid compiler pessimixations. clang understands them a bit better than inline asm, and generates better looking code which also runs better for cem, but for me it just at the same speed or slower by doing excessive unrollowing in all the wrong places. gcc-4.2.1 also doesn't understand what it is doing with unrolling, but with -O3 somehow it does more unrolling that helps. Reduce 1 of the the compiler pessimizations (copying a variable which already satisfies an "rm" constraint in a good way by being in memory and not used again, to different memory and accessing it there. Force copying it to a register instead). Try to optimize the inner loops significantly, so as to run at full speed on smaller inputs. The algorithm is already very MD, and was tuned for the throughput of 3 crc32 instructions per cycle found on at least Sandybridge through Haswell. Now it is even more tuned for this, so depends more on the compiler not rearranging or unrolling things too much. The main inner loop for should have no difficulty runing at full speed on these CPUs unless the compiler unrolls it too much. However, the main inner loop wasn't even used for buffers smaller than 24K. Now it is used for buffers larger than 384 bytes. Now it is not so long, and the main outer loop is used more. The new optimization is to try to arrange that the outer loop runs in parallel with the next inner loop except for the final iteration; then reduce the loop sizes significantly to take advantage of this. Approved by: cem Not tested in production by: bde
2017-03-26 12:31:48 +02:00
libkern/x86/crc32_sse42.c standard
libkern/memmove.c standard
libkern/memset.c standard
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 09:58:16 +01:00
#
# IA32 binary support
#
Provide groundwork for 32-bit binary compatibility on non-x86 platforms, for upcoming 64-bit PowerPC and MIPS support. This renames the COMPAT_IA32 option to COMPAT_FREEBSD32, removes some IA32-specific code from MI parts of the kernel and enhances the freebsd32 compatibility code to support big-endian platforms. Reviewed by: kib, jhb
2010-03-11 15:49:06 +01:00
#amd64/ia32/ia32_exception.S optional compat_freebsd32
amd64/ia32/ia32_reg.c optional compat_freebsd32
amd64/ia32/ia32_signal.c optional compat_freebsd32
amd64/ia32/ia32_sigtramp.S optional compat_freebsd32
amd64/ia32/ia32_syscall.c optional compat_freebsd32
amd64/ia32/ia32_misc.c optional compat_freebsd32
compat/ia32/ia32_sysvec.c optional compat_freebsd32
- change the example of compiling only specific modules to not contain the linux module, since it is not cross-platform - move linprocfs from "files" and "options" to architecture specific files, since it only makes sense to build this for those architectures, where we also have a linuxolator - disable the build of the linuxolator on our tier-2 architecture "Alpha": * we don't have a linux_base port which supports Alpha and at the same time is not outdated/obsoleted upstream/in a good condition/ currently working * the upcomming new default linux base port is based upon Fedora Core 3 (security support via http://www.fedoralegacy.org), which isn't available for Alpha (like the current default linux base port which is based upon Red Hat 8) * nobody answered my request for testing it ~1 month ago on current@ and alpha@ (it doesn't surprises me, see above) * a SoC student wouldn't have to waste time on something which nobody is willing to test This does not remove the alpha specific MD files of the linuxolator yet. Discussed on: arch (mostly silence) Spiritual support by: scottl
2006-05-07 20:12:18 +02:00
compat/linprocfs/linprocfs.c optional linprocfs
Add in linsysfs. A linux 2.6 like sys filesystem to pacify the Linux LSI MegaRAID SAS utility. Sponsored by: IronPort Systems Man page help from: brueffer
2006-05-10 00:27:01 +02:00
compat/linsysfs/linsysfs.c optional linsysfs
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 09:55:06 +02:00
#
# Linux/i386 binary support
#
amd64/linux32/linux32_dummy.c optional compat_linux32
amd64/linux32/linux32_machdep.c optional compat_linux32
Fix the dependency for the linux_support.s, explicitely add linux_assym.h. Reported by: rwatson In collaboration with: rdivacky Sponsored by: Google SoC 2007
2007-05-23 17:45:52 +02:00
amd64/linux32/linux32_support.s optional compat_linux32 \
dependency "linux32_assym.h"
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 09:55:06 +02:00
amd64/linux32/linux32_sysent.c optional compat_linux32
amd64/linux32/linux32_sysvec.c optional compat_linux32
Move futex support code from <arch>/support.s into linux compat directory. Implement all futex atomic operations in assembler to not depend on the fuword() that does not allow to distinguish between -1 and failure return. Correctly return 0 from atomic operations on success. In collaboration with: rdivacky Tested by: Scot Hetzel <swhetzel gmail com>, Milos Vyletel <mvyletel mzm cz> Sponsored by: Google SoC 2007
2007-05-23 10:33:06 +02:00
compat/linux/linux_emul.c optional compat_linux32
Share a single bsd-linux errno table across MD consumers Three copies of the linuxulator linux_sysvec.c contained identical BSD to Linux errno translation tables, and future work to support other architectures will also use the same table. Move the table to a common file to be used by all. Make it 'const int' to place it in .rodata. (Some existing Linux architectures use MD errno values, but x86 and Arm share the generic set.) This change should introduce no functional change; a followup will add missing errno values. MFC after: 3 weeks Sponsored by: Turing Robotic Industries Inc. Differential Revision: https://reviews.freebsd.org/D14665
2018-03-16 15:46:38 +01:00
compat/linux/linux_errno.c optional compat_linux32
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 09:55:06 +02:00
compat/linux/linux_file.c optional compat_linux32
Move linux_clone(), linux_fork(), linux_vfork() to a MI path.
2011-02-12 19:17:12 +01:00
compat/linux/linux_fork.c optional compat_linux32
Add the linux 2.6.x stuff (not used by default!): - TLS - complete - pid/tid mangling - complete - thread area - complete - futexes - complete with issues - clone() extension - complete with some possible minor issues - mq*/timer*/clock* stuff - complete but untested and the mq* stuff is disabled when not build as part of the kernel with native FreeBSD mq* support (module support for this will come later) Tested with: - linux-firefox - works, tested - linux-opera - works, tested - linux-realplay - doesnt work, issue with futexes - linux-skype - doesnt work, issue with futexes - linux-rt2-demo - works, tested - linux-acroread - doesnt work, unknown reason (coredump) and sometimes issue with futexes - various unix utilities in linux-base-gentoo3 and linux-base-fc4: everything tried worked On amd64 not everything is supported like on i386, the catchup is planned for later when the remaining bugs in the new functions are fixed. To test this new stuff, you have to run sysctl compat.linux.osrelease=2.6.16 to switch back use sysctl compat.linux.osrelease=2.4.2 Don't switch while running a linux program, strange things may or may not happen. Sponsored by: Google SoC 2006 Submitted by: rdivacky Some suggestions/help by: jhb, kib, manu@NetBSD.org, netchild
2006-08-15 14:54:30 +02:00
compat/linux/linux_futex.c optional compat_linux32
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 09:55:06 +02:00
compat/linux/linux_getcwd.c optional compat_linux32
compat/linux/linux_ioctl.c optional compat_linux32
compat/linux/linux_ipc.c optional compat_linux32
compat/linux/linux_mib.c optional compat_linux32
compat/linux/linux_misc.c optional compat_linux32
Add linux_mmap.c to the appropriate conf/files. Reported by: kib@ MFC after: 1 week
2016-07-10 10:38:10 +02:00
compat/linux/linux_mmap.c optional compat_linux32
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 09:55:06 +02:00
compat/linux/linux_signal.c optional compat_linux32
compat/linux/linux_socket.c optional compat_linux32
compat/linux/linux_stats.c optional compat_linux32
compat/linux/linux_sysctl.c optional compat_linux32
Add the linux 2.6.x stuff (not used by default!): - TLS - complete - pid/tid mangling - complete - thread area - complete - futexes - complete with issues - clone() extension - complete with some possible minor issues - mq*/timer*/clock* stuff - complete but untested and the mq* stuff is disabled when not build as part of the kernel with native FreeBSD mq* support (module support for this will come later) Tested with: - linux-firefox - works, tested - linux-opera - works, tested - linux-realplay - doesnt work, issue with futexes - linux-skype - doesnt work, issue with futexes - linux-rt2-demo - works, tested - linux-acroread - doesnt work, unknown reason (coredump) and sometimes issue with futexes - various unix utilities in linux-base-gentoo3 and linux-base-fc4: everything tried worked On amd64 not everything is supported like on i386, the catchup is planned for later when the remaining bugs in the new functions are fixed. To test this new stuff, you have to run sysctl compat.linux.osrelease=2.6.16 to switch back use sysctl compat.linux.osrelease=2.4.2 Don't switch while running a linux program, strange things may or may not happen. Sponsored by: Google SoC 2006 Submitted by: rdivacky Some suggestions/help by: jhb, kib, manu@NetBSD.org, netchild
2006-08-15 14:54:30 +02:00
compat/linux/linux_time.c optional compat_linux32
Implement most of timer_{create,settime,gettime,getoverrun,delete} for amd64/linux32. Fix the entirely bogus (untested) version from r161310 for i386/linux using the same shared code in compat/linux. It is unclear to me if we could support more clock mappings but the current set allows me to successfully run commercial 32bit linux software under linuxolator on amd64. Reviewed by: jhb Differential Revision: D784 MFC after: 3 days Sponsored by: DARPA, AFRL
2014-09-18 10:36:45 +02:00
compat/linux/linux_timer.c optional compat_linux32
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 09:55:06 +02:00
compat/linux/linux_uid16.c optional compat_linux32
compat/linux/linux_util.c optional compat_linux32
Implement vdso - virtual dynamic shared object. Through vdso Linux exposes functions from kernel with proper DWARF CFI information so that it becomes easier to unwind through them. Using vdso is a mandatory for a thread cancelation && cleanup on a modern glibc. Differential Revision: https://reviews.freebsd.org/D1060
2015-05-24 17:28:17 +02:00
compat/linux/linux_vdso.c optional compat_linux32
Introduce a new module linux_common.ko which is intended for the following primary purposes: 1. Remove the dependency of linsysfs and linprocfs modules from linux.ko, which will be architecture specific on amd64. 2. Incorporate into linux_common.ko general code for platforms on which we'll support two Linuxulator modules (for both instruction set - 32 & 64 bit). 3. Move malloc(9) declaration to linux_common.ko, to enable getting memory usage statistics properly. Currently linux_common.ko incorporates a code from linux_mib.c and linux_util.c and linprocfs, linsysfs and linux kernel modules depend on linux_common.ko. Temporarily remove dtrace garbage from linux_mib.c and linux_util.c Differential Revision: https://reviews.freebsd.org/D1072 In collaboration with: Vassilis Laganakos. Reviewed by: trasz
2015-05-24 17:51:18 +02:00
compat/linux/linux_common.c optional compat_linux32
Implement epoll family system calls. This is a tiny wrapper around kqueue() to implement epoll subset of functionality. The kqueue user data are 32bit on i386 which is not enough for epoll user data, so we keep user data in the proc emuldata. Initial patch developed by rdivacky@ in 2007, then extended by Yuri Victorovich @ r255672 and finished by me in collaboration with mjg@ and jillies@. Differential Revision: https://reviews.freebsd.org/D1092
2015-05-24 18:41:39 +02:00
compat/linux/linux_event.c optional compat_linux32
Rework signal code to allow using it by other modules, like linprocfs: 1. Linux sigset always 64 bit on all platforms. In order to move Linux sigset code to the linux_common module define it as 64 bit int. Move Linux sigset manipulation routines to the MI path. 2. Move Linux signal number definitions to the MI path. In general, they are the same on all platforms except for a few signals. 3. Map Linux RT signals to the FreeBSD RT signals and hide signal conversion tables to avoid conversion errors. 4. Emulate Linux SIGPWR signal via FreeBSD SIGRTMIN signal which is outside of allowed on Linux signal numbers. PR: 197216
2015-05-24 19:47:20 +02:00
compat/linux/linux.c optional compat_linux32
Add in the Linux IOCTL shim and create the megadev0 device so Linux LSI MegaRaid tools can run on FreeBSD until Linux emulation. Add in the Linux IOCTL shim and create the megadev0 device so Linux LSI MegaRaid tools can run on FreeBSD until Linux emulation. Add glue to build the modules but don't tie it into the build yet until I test it from the CVS repo. via the mirror on an amd64 machine. Tie this into the Linux32 emulation on amd64 so the tools can run on amd64 kernel. Cleaned up by: ps (amr_linux.c)
2006-01-24 22:13:50 +01:00
dev/amr/amr_linux.c optional compat_linux32 amr
Add in a bunch of things to the mfi driver: - Linux ioctl support, with the other Linux changes MegaCli will run if you mount linprocfs & linsysfs then set sysctl compat.linux.osrelease=2.6.12 or similar. This works on i386. It should work on amd64 but not well tested yet. StoreLib may or may not work. Remember to kldload mfi_linux. - Add in AEN (Async Event Notification) support so we can get messages from the firmware when something happens. Not all messages are in defined in event detail. Use event_log to try to figure out what happened. - Try to implement something like SIGIO for StoreLib. Since mrmonitor doesn't work right I can't fully test it. StoreLib works best with the rh9 base. In theory mrmonitor isn't needed due to native driver support of AEN :-) Now we can configure and monitor the RAID better. Submitted by: IronPort Systems.
2006-05-19 01:30:48 +02:00
dev/mfi/mfi_linux.c optional compat_linux32 mfi
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 06:41:18 +01:00
#
# Windows NDIS driver support
#
compat/ndis/kern_ndis.c optional ndisapi pci
compat/ndis/kern_windrv.c optional ndisapi pci
compat/ndis/subr_hal.c optional ndisapi pci
compat/ndis/subr_ndis.c optional ndisapi pci
compat/ndis/subr_ntoskrnl.c optional ndisapi pci
compat/ndis/subr_pe.c optional ndisapi pci
- Correct one aspect of the driver_object/device_object/IRP framework: when we create a PDO, the driver_object associated with it is that of the parent driver, not the driver we're trying to attach. For example, if we attach a PCI device, the PDO we pass to the NdisAddDevice() function should contain a pointer to fake_pci_driver, not to the NDIS driver itself. For PCI or PCMCIA devices this doesn't matter because the child never needs to talk to the parent bus driver, but for USB, the child needs to be able to send IRPs to the parent USB bus driver, and for that to work the parent USB bus driver has to be hung off the PDO. This involves modifying windrv_lookup() so that we can search for bus drivers by name, if necessary. Our fake bus drivers attach themselves as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them using those names. The individual attachment stubs now create and attach PDOs to the parent bus drivers instead of hanging them off the NDIS driver's object, and in if_ndis.c, we now search for the correct driver object depending on the bus type, and use that to find the correct PDO. With this fix, I can get my sample USB ethernet driver to deliver an IRP to my fake parent USB bus driver's dispatch routines. - Add stub modules for USB support: subr_usbd.c, usbd_var.h and if_ndis_usb.c. The subr_usbd.c module is hooked up the build but currently doesn't do very much. It provides the stub USB parent driver object and a dispatch routine for IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub compiles, but is not hooked up to the build yet. I'm putting these here so I can keep them under source code control as I flesh them out.
2005-02-24 22:49:14 +01:00
compat/ndis/subr_usbd.c optional ndisapi pci
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 06:41:18 +01:00
compat/ndis/winx64_wrap.S optional ndisapi pci
Be more conservative and compile libkern/memset.c only on architectures than need it. These are i386, amd64 and powerpc so far.
2007-04-06 06:51:50 +02:00
#
Remove leftover from r282269. MFC after: 2 weeks X-MFC with: r282269
2015-04-30 19:49:35 +02:00
# x86 real mode BIOS emulator, required by dpms/pci/vesa
Hide x86bios stuff in i386/amd64 specific files as atkbdc would get these stuff into build.
2009-09-22 09:10:23 +02:00
#
Remove leftover from r282269. MFC after: 2 weeks X-MFC with: r282269
2015-04-30 19:49:35 +02:00
compat/x86bios/x86bios.c optional x86bios | dpms | pci | vesa
contrib/x86emu/x86emu.c optional x86bios | dpms | pci | vesa
Introduce the new kernel sub-tree x86 which should contain all the code shared and generalized between our current amd64, i386 and pc98. This is just an initial step that should lead to a more complete effort. For the moment, a very simple porting of cpufreq modules, BIOS calls and the whole MD specific ISA bus part is added to the sub-tree but ideally a lot of code might be added and more shared support should grow. Sponsored by: Sandvine Incorporated Reviewed by: emaste, kib, jhb, imp Discussed on: arch MFC: 3 weeks
2010-02-25 15:13:39 +01:00
#
bhyve import part 2 of 2, guest kernel changes. This branch is now considered frozen: future bhyve development will take place in a branch off -CURRENT. sys/dev/bvm/bvm_console.c sys/dev/bvm/bvm_dbg.c - simple console driver/gdb debug port used for bringup. supported by user-space bhyve executable sys/conf/options.amd64 sys/amd64/amd64/minidump_machdep.c - allow NKPT to be set in the kernel config file sys/amd64/conf/GENERIC - mptable config options; bhyve user-space executable creates an mptable with number of CPUs, and optional vendor extension - add bvm console/debug - set NKPT to 512 to allow loading of large RAM disks from the loader - include kdb/gdb sys/amd64/amd64/local_apic.c sys/amd64/amd64/apic_vector.S sys/amd64/include/specialreg.h - if x2apic mode available, use MSRs to access the local APIC, otherwise fall back to 'classic' MMIO mode sys/amd64/amd64/mp_machdep.c - support AP spinup on CPU models that don't have real-mode support by overwriting the real-mode page with a message that supplies the bhyve user-space executable with enough information to start the AP directly in 64-bit mode. sys/amd64/amd64/vm_machdep.c - insert pause statements into cpu shutdown busy-wait loops sys/dev/blackhole/blackhole.c sys/modules/blackhole/Makefile - boot-time loadable module that claims all PCI bus/slot/funcs specified in an env var that are to be used for PCI passthrough sys/amd64/amd64/intr_machdep.c - allow round-robin assignment of device interrupts to CPUs to be disabled from the loader sys/amd64/include/bus.h - convert string ins/outs instructions to loops of individual in/out since bhyve doesn't support these yet sys/kern/subr_bus.c - if the device was no created with a fixed devclass, then remove it's association with the devclass it was associated with during probe. Otherwise, new drivers do not get a chance to probe/attach since the device will stay married to the first driver that it probed successfully but failed to attach. Sponsored by: NetApp, Inc.
2011-05-14 20:37:24 +02:00
# bvm console
#
dev/bvm/bvm_console.c optional bvmconsole
dev/bvm/bvm_dbg.c optional bvmdebug
First cut at porting the kernel portions of 221828 and 221905 from the BHyVe reference branch to HEAD.
2011-05-14 22:35:01 +02:00
#
Remove pc98 support completely. I thank all developers and contributors for pc98. Relnotes: yes
2017-01-28 03:22:15 +01:00
# x86 shared code between IA32 and AMD64 architectures
Introduce the new kernel sub-tree x86 which should contain all the code shared and generalized between our current amd64, i386 and pc98. This is just an initial step that should lead to a more complete effort. For the moment, a very simple porting of cpufreq modules, BIOS calls and the whole MD specific ISA bus part is added to the sub-tree but ideally a lot of code might be added and more shared support should grow. Sponsored by: Sandvine Incorporated Reviewed by: emaste, kib, jhb, imp Discussed on: arch MFC: 3 weeks
2010-02-25 15:13:39 +01:00
#
Now OsdEnvironment.c is identical on amd64 and i386. Move it to a new home.
2010-11-09 01:27:18 +01:00
x86/acpica/OsdEnvironment.c optional acpi
Refactor acpi_machdep.c for amd64 and i386, move APM emulation into a new file acpi_apm.c, and place it on sys/x86/acpica.
2010-11-10 02:29:56 +01:00
x86/acpica/acpi_apm.c optional acpi
Some fixes for r236772. - Remove cpuset stopped_cpus which is no longer used. - Add a short comment for cpuset suspended_cpus clearing. - Fix the un-ordered x86/acpica/acpi_wakeup.c in conf/files.amd64 and i386. Pointed-out by: attilio@
2012-06-10 04:38:51 +02:00
x86/acpica/acpi_wakeup.c optional acpi
Move the MADT parser for amd64 and i386 to sys/x86/acpica now that it is identical on both platforms.
2010-11-08 21:57:02 +01:00
x86/acpica/madt.c optional acpi
Add a parser for the ACPI SRAT table for amd64 and i386. It sets PCPU(domain) for each CPU and populates a mem_affinity array suitable for the NUMA support in the physical memory allocator. Reviewed by: alc
2010-07-27 22:40:46 +02:00
x86/acpica/srat.c optional acpi
Introduce the new kernel sub-tree x86 which should contain all the code shared and generalized between our current amd64, i386 and pc98. This is just an initial step that should lead to a more complete effort. For the moment, a very simple porting of cpufreq modules, BIOS calls and the whole MD specific ISA bus part is added to the sub-tree but ideally a lot of code might be added and more shared support should grow. Sponsored by: Sandvine Incorporated Reviewed by: emaste, kib, jhb, imp Discussed on: arch MFC: 3 weeks
2010-02-25 15:13:39 +01:00
x86/bios/smbios.c optional smbios
x86/bios/vpd.c optional vpd
x86/cpufreq/powernow.c optional cpufreq
x86/cpufreq/est.c optional cpufreq
x86/cpufreq/hwpstate.c optional cpufreq
x86/cpufreq/p4tcc.c optional cpufreq
Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month
2013-10-28 14:33:29 +01:00
x86/iommu/busdma_dmar.c optional acpi acpi_dmar pci
x86/iommu/intel_ctx.c optional acpi acpi_dmar pci
x86/iommu/intel_drv.c optional acpi acpi_dmar pci
x86/iommu/intel_fault.c optional acpi acpi_dmar pci
x86/iommu/intel_gas.c optional acpi acpi_dmar pci
x86/iommu/intel_idpgtbl.c optional acpi acpi_dmar pci
Use VT-d interrupt remapping block (IR) to perform FSB messages translation. In particular, despite IO-APICs only take 8bit apic id, IR translation structures accept 32bit APIC Id, which allows x2APIC mode to function properly. Extend msi_cpu of struct msi_intrsrc and io_cpu of ioapic_intsrc to full int from one byte. KPI of IR is isolated into the x86/iommu/iommu_intrmap.h, to avoid bringing all dmar headers into interrupt code. The non-PCI(e) devices which generate message interrupts on FSB require special handling. The HPET FSB interrupts are remapped, while DMAR interrupts are not. For each msi and ioapic interrupt source, the iommu cookie is added, which is in fact index of the IRE (interrupt remap entry) in the IR table. Cookie is made at the source allocation time, and then used at the map time to fill both IRE and device registers. The MSI address/data registers and IO-APIC redirection registers are programmed with the special values which are recognized by IR and used to restore the IRE index, to find proper delivery mode and target. Map all MSI interrupts in the block when msi_map() is called. Since an interrupt source setup and dismantle code are done in the non-sleepable context, flushing interrupt entries cache in the IR hardware, which is done async and ideally waits for the interrupt, requires busy-wait for queue to drain. The dmar_qi_wait_for_seq() is modified to take a boolean argument requesting busy-wait for the written sequence number instead of waiting for interrupt. Some interrupts are configured before IR is initialized, e.g. ACPI SCI. Add intr_reprogram() function to reprogram all already configured interrupts, and call it immediately before an IR unit is enabled. There is still a small window after the IO-APIC redirection entry is reprogrammed with cookie but before the unit is enabled, but to fix this properly, IR must be started much earlier. Add workarounds for 5500 and X58 northbridges, some revisions of which have severe flaws in handling IR. Use the same identification methods as employed by Linux. Review: https://reviews.freebsd.org/D1892 Reviewed by: neel Discussed with: jhb Tested by: glebius, pho (previous versions) Sponsored by: The FreeBSD Foundation MFC after: 3 weeks
2015-03-19 14:57:47 +01:00
x86/iommu/intel_intrmap.c optional acpi acpi_dmar pci
Add support for queued invalidation. Right now, the semaphore write is scheduled after each batch, which is not optimal and must be tuned. Discussed with: alc Tested by: pho MFC after: 1 month
2013-11-01 18:38:52 +01:00
x86/iommu/intel_qi.c optional acpi acpi_dmar pci
Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month
2013-10-28 14:33:29 +01:00
x86/iommu/intel_quirks.c optional acpi acpi_dmar pci
x86/iommu/intel_utils.c optional acpi acpi_dmar pci
Introduce the new kernel sub-tree x86 which should contain all the code shared and generalized between our current amd64, i386 and pc98. This is just an initial step that should lead to a more complete effort. For the moment, a very simple porting of cpufreq modules, BIOS calls and the whole MD specific ISA bus part is added to the sub-tree but ideally a lot of code might be added and more shared support should grow. Sponsored by: Sandvine Incorporated Reviewed by: emaste, kib, jhb, imp Discussed on: arch MFC: 3 weeks
2010-02-25 15:13:39 +01:00
x86/isa/atpic.c optional atpic isa
Fix a mis-change about the compiling of atrtc.c. Sponsored by: Sandvine Incorporated Reported by: Giovanni Trematerra <giovannit dot trematerra at gmail dot com> MFC: 3 weeks X-MFC: r204309
2010-02-25 16:00:27 +01:00
x86/isa/atrtc.c standard
Introduce the new kernel sub-tree x86 which should contain all the code shared and generalized between our current amd64, i386 and pc98. This is just an initial step that should lead to a more complete effort. For the moment, a very simple porting of cpufreq modules, BIOS calls and the whole MD specific ISA bus part is added to the sub-tree but ideally a lot of code might be added and more shared support should grow. Sponsored by: Sandvine Incorporated Reviewed by: emaste, kib, jhb, imp Discussed on: arch MFC: 3 weeks
2010-02-25 15:13:39 +01:00
x86/isa/clock.c standard
Allow a native i386 kernel to be built with 'nodevice atpic'. Just as on amd64, if 'device isa' is present quiesce the 8259A's during boot and resume from suspend. While here, be more selective on amd64 about which kernel configurations need elcr.c. MFC after: 2 weeks
2012-03-09 20:42:48 +01:00
x86/isa/elcr.c optional atpic isa | mptable
Introduce the new kernel sub-tree x86 which should contain all the code shared and generalized between our current amd64, i386 and pc98. This is just an initial step that should lead to a more complete effort. For the moment, a very simple porting of cpufreq modules, BIOS calls and the whole MD specific ISA bus part is added to the sub-tree but ideally a lot of code might be added and more shared support should grow. Sponsored by: Sandvine Incorporated Reviewed by: emaste, kib, jhb, imp Discussed on: arch MFC: 3 weeks
2010-02-25 15:13:39 +01:00
x86/isa/isa.c standard
x86/isa/isa_dma.c standard
x86/isa/nmi.c standard
x86/isa/orm.c optional isa
Move {amd64,i386}/pci/pci_bus.c and {amd64,i386}/include/pci_cfgreg.h to the x86 tree. The $PIR code is still only enabled on i386 and not amd64. While here, make the qpi(4) driver on conditional on 'device pci'.
2011-06-22 23:04:13 +02:00
x86/pci/pci_bus.c optional pci
x86/pci/qpi.c optional pci
Move i386/i386/autoconf.c to sys/x86/x86 and use it on both amd64 and i386.
2016-04-04 01:03:54 +02:00
x86/x86/autoconf.c standard
Better support memory mapped console devices, such as VGA and EFI frame buffers and memory mapped UARTs. 1. Delay calling cninit() until after pmap_bootstrap(). This makes sure we have PMAP initialized enough to add translations. Keep kdb_init() after cninit() so that we have console when we need to break into the debugger on boot. 2. Unfortunately, the ATPIC code had be moved as well so as to avoid a spurious trap #30. The reason for which is not known at this time. 3. In pmap_mapdev_attr(), when we need to map a device prior to the VM system being initialized, use virtual_avail as the KVA to map the device at. In particular, avoid using the direct map on amd64 because we can't demote by virtue of not being able to allocate yet. Keep track of the translation. Re-use the translation after the VM has been initialized to not waste KVA and to satisfy the assumption in uart(4) that the handle returned for the low-level console is the same as later returned when the device is probed and attached. 4. In pmap_unmapdev() remove the mapping from the table when called pre-init. Otherwise keep the mapping. During bus probe and attach device resources are mapped and unmapped multiple times, which would have us destroy the mapping used by the low-level console. 5. In pmap_init(), set pmap_initialized to signal that we're not pre-init anymore. On amd64, bring the direct map in sync with the translations created at that time. 6. Implement bus_space_map() and bus_space_unmap() for real: when the tag corresponds to memory space, call the corresponding pmap_mapdev() and pmap_unmapdev() functions to construct and actual handle. 7. In efifb.c and vt_vga.c, remove the crutches and hacks and simply call pmap_mapdev_attr() or bus_space_map() as desired. Notes: 1. uart(4) already used bus_space_map() during low-level console setup but since serial ports have traditionally been I/O port based, the lack of a proper implementation for said function was not a problem. It has always supported memory mapped UARTs for low-level consoles by setting hw.uart.console accordingly. 2. The use of the direct map on amd64 without setting caching attributes has been a bigger problem than previously thought. This change has the fortunate (and unexpected) side-effect of fixing various EFI frame buffer problems (though not all). PR: 191564, 194952 Special thanks to: 1. XipLink, Inc -- generously donated an Intel Bay Trail E3800 based eval board (ADLE3800PC). 2. The FreeBSD Foundation, in particular emaste@ -- for UEFI support in general and testing. 3. Everyone who tested the proposed for PR 191564. 4. jhb@ and kib@ for being a soundboard and applying a clue bat if so needed.
2015-08-12 17:26:32 +02:00
x86/x86/bus_machdep.c standard
Add a virtual table for the busdma methods on x86, to allow different busdma implementations to coexist. Copy busdma_machdep.c to busdma_bounce.c, which is still a single implementation of the busdma interface on x86 for now. The busdma_machdep.c only contains common and dispatch code. Tested by: pho (as part of the larger patch) Sponsored by: The FreeBSD Foundation MFC after: 1 month
2013-10-27 23:05:10 +01:00
x86/x86/busdma_bounce.c standard
Replace i386/i386/busdma_machdep.c and amd64/amd64/busdma_machdep.c (which are identical) with a single x86/x86/busdma_machdep.c.
2010-12-09 07:41:50 +01:00
x86/x86/busdma_machdep.c standard
Move some common code from sys/amd64/amd64/machdep.c and sys/i386/i386/machdep.c to new file sys/x86/x86/cpu_machdep.c. Most of the code is related to the idle handling. Discussed with: pluknet Sponsored by: The FreeBSD Foundation
2015-04-22 14:32:14 +02:00
x86/x86/cpu_machdep.c standard
Merge dump_machdep.c i386/amd64 under the x86 subtree. Sponsored by: Sandvine Incorporated Tested by: gianni
2010-10-26 14:46:26 +02:00
x86/x86/dump_machdep.c standard
Add basic support for FDT to i386 & amd64. This change includes: 1. Common headers for fdt.h and ofw_machdep.h under x86/include with indirections under i386/include and amd64/include. 2. New modinfo for loader provided FDT blob. 3. Common x86_init_fdt() called from hammer_time() on amd64 and init386() on i386. 4. Split-off FDT specific low-level console functions from FDT bus methods for the uart(4) driver. The low-level console logic has been moved to uart_cpu_fdt.c and is used for arm, mips & powerpc only. The FDT bus methods are shared across all architectures. 5. Add dev/fdt/fdt_x86.c to hold the fdt_fixup_table[] and the fdt_pic_table[] arrays. Both are empty right now. FDT addresses are I/O ports on x86. Since the core FDT code does not handle different address spaces, adding support for both I/O ports and memory addresses requires some thought and discussion. It may be better to use a compile-time option that controls this. Obtained from: Juniper Networks, Inc.
2013-05-21 05:05:49 +02:00
x86/x86/fdt_machdep.c optional fdt
Merge the amd64 and i386 identcpu.c into a single x86 implementation. This brings the structured extended features mask and VT-x reporting to i386 and Intel cache and TLB info (under bootverbose) to amd64.
2014-09-04 16:26:25 +02:00
x86/x86/identcpu.c standard
Move i386's intr_machdep.c to the x86 tree and share it with amd64.
2012-03-09 21:43:29 +01:00
x86/x86/intr_machdep.c standard
Move the I/O APIC code to the x86 tree since it is identical on i386 and amd64.
2010-06-08 19:51:21 +02:00
x86/x86/io_apic.c standard
Move the legacy(4) driver to x86.
2012-03-30 21:10:14 +02:00
x86/x86/legacy.c standard
Move the I/O APIC code to the x86 tree since it is identical on i386 and amd64.
2010-06-08 19:51:21 +02:00
x86/x86/local_apic.c standard
Move the machine check support code to the x86 tree since it is identical on i386 and amd64. Requested by: alc
2010-06-08 20:04:07 +02:00
x86/x86/mca.c standard
Merge i386 and amd64 mtrr drivers. Reviewed by: royger, jhb Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D9648
2017-02-17 22:08:32 +01:00
x86/x86/x86_mem.c optional mem
Merge the mptable support from MD bits to x86 subtree. Sponsored by: Sandvine Incorporated Discussed with: jhb
2010-10-28 09:58:06 +02:00
x86/x86/mptable.c optional mptable
x86/x86/mptable_pci.c optional mptable pci
Move common code from sys/i386/i386/mp_machdep.c and sys/amd64/amd64/mp_machdep.c, to the new common x86 source sys/x86/x86/mp_x86.c. Proposed and reviewed by: jhb Review: https://reviews.freebsd.org/D2347 Sponsored by: The FreeBSD Foundation
2015-04-24 18:20:56 +02:00
x86/x86/mp_x86.c optional smp
Merge i386 and amd64 variants of mp_watchdog.c into x86/, there is no difference between files. For pc98, put x86/mp_x86.c into the same place as used by i386 file list. Fix typo in comment. Sponsored by: The FreeBSD Foundation MFC after: 1 week
2016-08-03 15:51:53 +02:00
x86/x86/mp_watchdog.c optional mp_watchdog smp
Move the MD support for PCI message signalled interrupts to the x86 tree as it is identical for i386 and amd64.
2010-06-08 20:36:03 +02:00
x86/x86/msi.c optional pci
Merge nexus.c from amd64 and i386 to x86 subtree. Sponsored by: Sandvine Incorporated Tested by: gianni
2010-10-28 18:31:39 +02:00
x86/x86/nexus.c standard
Generalized parts of the XEN timer code into a generic pvclock KVM clock shares the same data structures between the guest and the host as Xen so it makes sense to just have a single copy of this code. Differential Revision: https://reviews.freebsd.org/D1429 Reviewed by: royger (eariler version) MFC after: 1 month
2015-02-04 09:26:43 +01:00
x86/x86/pvclock.c standard
Merge stack(9) implementations for i386 and amd64 under x86/. Reviewed by: jhb, kib Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D3255
2015-09-11 05:24:07 +02:00
x86/x86/stack_machdep.c optional ddb | stack
Merge sys/amd64/amd64/tsc.c and sys/i386/i386/tsc.c and move to sys/x86/x86. Discussed with: avg
2010-12-08 01:09:24 +01:00
x86/x86/tsc.c standard
xen: implement an early timer for Xen PVH When running as a PVH guest, there's no emulated i8254, so we need to use the Xen PV timer as the early source for DELAY. This change allows for different implementations of the early DELAY function and implements a Xen variant for it. Approved by: gibbs Sponsored by: Citrix Systems R&D dev/xen/timer/timer.c: dev/xen/timer/timer.h: - Implement Xen early delay functions using the PV timer and declare them. x86/include/init.h: - Add hooks for early clock source initialization and early delay functions. i386/i386/machdep.c: pc98/pc98/machdep.c: amd64/amd64/machdep.c: - Set early delay hooks to use the i8254 on bare metal. - Use clock_init (that will in turn make use of init_ops) to initialize the early clock source. amd64/include/clock.h: i386/include/clock.h: - Declare i8254_delay and clock_init. i386/xen/clock.c: - Rename DELAY to i8254_delay. x86/isa/clock.c: - Introduce clock_init that will take care of initializing the early clock by making use of the init_ops hooks. - Move non ISA related delay functions to the newly introduced delay file. x86/x86/delay.c: - Add moved delay related functions. - Implement generic DELAY function that will use the init_ops hooks. x86/xen/pv.c: - Set PVH hooks for the early delay related functions in init_ops. conf/files.amd64: conf/files.i386: conf/files.pc98: - Add delay.c to the kernel build.
2014-03-11 11:20:42 +01:00
x86/x86/delay.c standard
Implement vector callback for PVHVM and unify event channel implementations Re-structure Xen HVM support so that: - Xen is detected and hypercalls can be performed very early in system startup. - Xen interrupt services are implemented using FreeBSD's native interrupt delivery infrastructure. - the Xen interrupt service implementation is shared between PV and HVM guests. - Xen interrupt handlers can optionally use a filter handler in order to avoid the overhead of dispatch to an interrupt thread. - interrupt load can be distributed among all available CPUs. - the overhead of accessing the emulated local and I/O apics on HVM is removed for event channel port events. - a similar optimization can eventually, and fairly easily, be used to optimize MSI. Early Xen detection, HVM refactoring, PVHVM interrupt infrastructure, and misc Xen cleanups: Sponsored by: Spectra Logic Corporation Unification of PV & HVM interrupt infrastructure, bug fixes, and misc Xen cleanups: Submitted by: Roger Pau Monné Sponsored by: Citrix Systems R&D sys/x86/x86/local_apic.c: sys/amd64/include/apicvar.h: sys/i386/include/apicvar.h: sys/amd64/amd64/apic_vector.S: sys/i386/i386/apic_vector.s: sys/amd64/amd64/machdep.c: sys/i386/i386/machdep.c: sys/i386/xen/exception.s: sys/x86/include/segments.h: Reserve IDT vector 0x93 for the Xen event channel upcall interrupt handler. On Hypervisors that support the direct vector callback feature, we can request that this vector be called directly by an injected HVM interrupt event, instead of a simulated PCI interrupt on the Xen platform PCI device. This avoids all of the overhead of dealing with the emulated I/O APIC and local APIC. It also means that the Hypervisor can inject these events on any CPU, allowing upcalls for different ports to be handled in parallel. sys/amd64/amd64/mp_machdep.c: sys/i386/i386/mp_machdep.c: Map Xen per-vcpu area during AP startup. sys/amd64/include/intr_machdep.h: sys/i386/include/intr_machdep.h: Increase the FreeBSD IRQ vector table to include space for event channel interrupt sources. sys/amd64/include/pcpu.h: sys/i386/include/pcpu.h: Remove Xen HVM per-cpu variable data. These fields are now allocated via the dynamic per-cpu scheme. See xen_intr.c for details. sys/amd64/include/xen/hypercall.h: sys/dev/xen/blkback/blkback.c: sys/i386/include/xen/xenvar.h: sys/i386/xen/clock.c: sys/i386/xen/xen_machdep.c: sys/xen/gnttab.c: Prefer FreeBSD primatives to Linux ones in Xen support code. sys/amd64/include/xen/xen-os.h: sys/i386/include/xen/xen-os.h: sys/xen/xen-os.h: sys/dev/xen/balloon/balloon.c: sys/dev/xen/blkback/blkback.c: sys/dev/xen/blkfront/blkfront.c: sys/dev/xen/console/xencons_ring.c: sys/dev/xen/control/control.c: sys/dev/xen/netback/netback.c: sys/dev/xen/netfront/netfront.c: sys/dev/xen/xenpci/xenpci.c: sys/i386/i386/machdep.c: sys/i386/include/pmap.h: sys/i386/include/xen/xenfunc.h: sys/i386/isa/npx.c: sys/i386/xen/clock.c: sys/i386/xen/mp_machdep.c: sys/i386/xen/mptable.c: sys/i386/xen/xen_clock_util.c: sys/i386/xen/xen_machdep.c: sys/i386/xen/xen_rtc.c: sys/xen/evtchn/evtchn_dev.c: sys/xen/features.c: sys/xen/gnttab.c: sys/xen/gnttab.h: sys/xen/hvm.h: sys/xen/xenbus/xenbus.c: sys/xen/xenbus/xenbus_if.m: sys/xen/xenbus/xenbusb_front.c: sys/xen/xenbus/xenbusvar.h: sys/xen/xenstore/xenstore.c: sys/xen/xenstore/xenstore_dev.c: sys/xen/xenstore/xenstorevar.h: Pull common Xen OS support functions/settings into xen/xen-os.h. sys/amd64/include/xen/xen-os.h: sys/i386/include/xen/xen-os.h: sys/xen/xen-os.h: Remove constants, macros, and functions unused in FreeBSD's Xen support. sys/xen/xen-os.h: sys/i386/xen/xen_machdep.c: sys/x86/xen/hvm.c: Introduce new functions xen_domain(), xen_pv_domain(), and xen_hvm_domain(). These are used in favor of #ifdefs so that FreeBSD can dynamically detect and adapt to the presence of a hypervisor. The goal is to have an HVM optimized GENERIC, but more is necessary before this is possible. sys/amd64/amd64/machdep.c: sys/dev/xen/xenpci/xenpcivar.h: sys/dev/xen/xenpci/xenpci.c: sys/x86/xen/hvm.c: sys/sys/kernel.h: Refactor magic ioport, Hypercall table and Hypervisor shared information page setup, and move it to a dedicated HVM support module. HVM mode initialization is now triggered during the SI_SUB_HYPERVISOR phase of system startup. This currently occurs just after the kernel VM is fully setup which is just enough infrastructure to allow the hypercall table and shared info page to be properly mapped. sys/xen/hvm.h: sys/x86/xen/hvm.c: Add definitions and a method for configuring Hypervisor event delievery via a direct vector callback. sys/amd64/include/xen/xen-os.h: sys/x86/xen/hvm.c: sys/conf/files: sys/conf/files.amd64: sys/conf/files.i386: Adjust kernel build to reflect the refactoring of early Xen startup code and Xen interrupt services. sys/dev/xen/blkback/blkback.c: sys/dev/xen/blkfront/blkfront.c: sys/dev/xen/blkfront/block.h: sys/dev/xen/control/control.c: sys/dev/xen/evtchn/evtchn_dev.c: sys/dev/xen/netback/netback.c: sys/dev/xen/netfront/netfront.c: sys/xen/xenstore/xenstore.c: sys/xen/evtchn/evtchn_dev.c: sys/dev/xen/console/console.c: sys/dev/xen/console/xencons_ring.c Adjust drivers to use new xen_intr_*() API. sys/dev/xen/blkback/blkback.c: Since blkback defers all event handling to a taskqueue, convert this task queue to a "fast" taskqueue, and schedule it via an interrupt filter. This avoids an unnecessary ithread context switch. sys/xen/xenstore/xenstore.c: The xenstore driver is MPSAFE. Indicate as much when registering its interrupt handler. sys/xen/xenbus/xenbus.c: sys/xen/xenbus/xenbusvar.h: Remove unused event channel APIs. sys/xen/evtchn.h: Remove all kernel Xen interrupt service API definitions from this file. It is now only used for structure and ioctl definitions related to the event channel userland device driver. Update the definitions in this file to match those from NetBSD. Implementing this interface will be necessary for Dom0 support. sys/xen/evtchn/evtchnvar.h: Add a header file for implemenation internal APIs related to managing event channels event delivery. This is used to allow, for example, the event channel userland device driver to access low-level routines that typical kernel consumers of event channel services should never access. sys/xen/interface/event_channel.h: sys/xen/xen_intr.h: Standardize on the evtchn_port_t type for referring to an event channel port id. In order to prevent low-level event channel APIs from leaking to kernel consumers who should not have access to this data, the type is defined twice: Once in the Xen provided event_channel.h, and again in xen/xen_intr.h. The double declaration is protected by __XEN_EVTCHN_PORT_DEFINED__ to ensure it is never declared twice within a given compilation unit. sys/xen/xen_intr.h: sys/xen/evtchn/evtchn.c: sys/x86/xen/xen_intr.c: sys/dev/xen/xenpci/evtchn.c: sys/dev/xen/xenpci/xenpcivar.h: New implementation of Xen interrupt services. This is similar in many respects to the i386 PV implementation with the exception that events for bound to event channel ports (i.e. not IPI, virtual IRQ, or physical IRQ) are further optimized to avoid mask/unmask operations that aren't necessary for these edge triggered events. Stubs exist for supporting physical IRQ binding, but will need additional work before this implementation can be fully shared between PV and HVM. sys/amd64/amd64/mp_machdep.c: sys/i386/i386/mp_machdep.c: sys/i386/xen/mp_machdep.c sys/x86/xen/hvm.c: Add support for placing vcpu_info into an arbritary memory page instead of using HYPERVISOR_shared_info->vcpu_info. This allows the creation of domains with more than 32 vcpus. sys/i386/i386/machdep.c: sys/i386/xen/clock.c: sys/i386/xen/xen_machdep.c: sys/i386/xen/exception.s: Add support for new event channle implementation.
2013-08-29 21:52:18 +02:00
x86/xen/hvm.c optional xenhvm
Remove support for Xen PV domU kernels. Support for HVM domU kernels remains. Xen is planning to phase out support for PV upstream since it is harder to maintain and has more overhead. Modern x86 CPUs include virtualization extensions that support HVM guests instead of PV guests. In addition, the PV code was i386 only and not as well maintained recently as the HVM code. - Remove the i386-only NATIVE option that was used to disable certain components for PV kernels. These components are now standard as they are on amd64. - Remove !XENHVM bits from PV drivers. - Remove various shims required for XEN (e.g. PT_UPDATES_FLUSH, LOAD_CR3, etc.) - Remove duplicate copy of <xen/features.h>. - Remove unused, i386-only xenstored.h. Differential Revision: https://reviews.freebsd.org/D2362 Reviewed by: royger Tested by: royger (i386/amd64 HVM domU and amd64 PVH dom0) Relnotes: yes
2015-04-30 17:48:48 +02:00
x86/xen/xen_intr.c optional xenhvm
xen: add PV/PVH kernel entry point Add the PV/PVH entry point and the low level functions for PVH early initialization. Approved by: gibbs Sponsored by: Citrix Systems R&D amd64/amd64/genassym.c: - Add __FreeBSD_version define to assym.s so it can be used for the Xen notes. amd64/amd64/locore.S: - Make bootstack global so it can be used from Xen kernel entry point. amd64/amd64/xen-locore.S: - Add Xen notes to the kernel. - Add the Xen PV entry point, that is going to call hammer_time_xen. amd64/include/asmacros.h: - Add ELFNOTE macros. i386/xen/xen_machdep.c: - Define HYPERVISOR_start_info for the XEN i386 PV port, which is going to be used in some shared code between PV and PVH. x86/xen/hvm.c: - Define HYPERVISOR_start_info for the PVH port. x86/xen/pv.c: - Introduce hammer_time_xen which is going to perform early setup for Xen PVH: - Setup shared Xen variables start_info, shared_info and xen_store. - Set guest type. - Create initial page tables as FreeBSD expects to find them. - Call into native init function (hammer_time). xen/xen-os.h: - Declare HYPERVISOR_start_info. conf/files.amd64: - Add amd64/amd64/locore.S and x86/xen/pv.c to the list of files.
2014-03-11 11:07:01 +01:00
x86/xen/pv.c optional xenhvm
xen: add an apic_enumerator for PVH On PVH there's no ACPI, so the CPU enumeration must be implemented using Xen hypercalls. Approved by: gibbs Sponsored by: Citrix Systems R&D x86/xen/pvcpu_enum.c: - Enumerate avaiable vCPUs on PVH by using the VCPUOP_is_up hypercall. - Set vcpu_id for PVH guests. conf/files.amd64: - Include the PV CPU enumerator in the XENHVM build.
2014-03-11 11:25:08 +01:00
x86/xen/pvcpu_enum.c optional xenhvm
xen: add hooks for Xen PV APIC Create the necessary hooks in order to provide a Xen PV APIC implementation that can be used on PVH. Most of the lapic ops shouldn't be called on Xen, since we trap those operations at a higher layer. Sponsored by: Citrix Systems R&D Approved by: gibbs x86/xen/hvm.c: x86/xen/xen_apic.c: - Move IPI related code to xen_apic.c x86/xen/xen_apic.c: - Introduce Xen PV APIC implementation, most of the functions of the lapic interface should never be called when running as PV(H) guest, so make sure FreeBSD panics when trying to use one of those. - Define the Xen APIC implementation in xen_apic_ops. xen/xen_pv.h: - Extern declaration of the xen_apic struct. x86/xen/pv.c: - Use xen_apic_ops as apic_ops when running as PVH guest. conf/files.amd64: conf/files.i386: - Include the xen_apic.c file in the build of i386/amd64 kernels using XENHVM.
2014-06-16 10:43:45 +02:00
x86/xen/xen_apic.c optional xenhvm
xen: introduce xenpv bus Create a dummy bus so top level Xen devices can attach to it (instead of attaching directly to the nexus). This allows to have all the Xen related devices grouped under a single bus. Sponsored by: Citrix Systems R&D Approved by: gibbs x86/xen/xenpv.c: - Attach the xenpv bus when running as a Xen guest. - Attach the ISA bus if needed, in order to attach syscons. conf/files.amd6: conf/files.i386: - Include the xenpv.c file in the build of i386/amd64 kernels using XENHVM. dev/xen/console/console.c: dev/xen/timer/timer.c: xen/xenstore/xenstore.c: - Attach to the xenpv bus instead of the Nexus. dev/xen/xenpci/xenpci.c: - Xen specific devices on PVHVM guests are no longer attached to the xenpci device, they are instead attached to the xenpv bus, remove the now unused methods.
2014-06-16 10:44:33 +02:00
x86/xen/xenpv.c optional xenhvm
xen: create a Xen nexus to use in PV/PVH Introduce a Xen specific nexus that is going to be used by Xen PV/PVH guests. Sponsored by: Citrix Systems R&D Approved by: gibbs x86/xen/xen_nexus.c: - Introduce a Nexus to use on Xen PV(H) guests, this prevents PV(H) guests from using the legacy Nexus. conf/files.amd64: conf/files.i386: - Add the xen nexus to the build.
2014-06-16 10:45:51 +02:00
x86/xen/xen_nexus.c optional xenhvm
msi: add Xen MSI implementation This patch adds support for MSI interrupts when running on Xen. Apart from adding the Xen related code needed in order to register MSI interrupts this patch also makes the msi_init function a hook in init_ops, so different MSI implementations can have different initialization functions. Sponsored by: Citrix Systems R&D xen/interface/physdev.h: - Add the MAP_PIRQ_TYPE_MULTI_MSI to map multi-vector MSI to the Xen public interface. x86/include/init.h: - Add a hook for setting custom msi_init methods. amd64/amd64/machdep.c: i386/i386/machdep.c: - Set the default msi_init hook to point to the native MSI initialization method. x86/xen/pv.c: - Set the Xen MSI init hook when running as a Xen guest. x86/x86/local_apic.c: - Call the msi_init hook instead of directly calling msi_init. xen/xen_intr.h: x86/xen/xen_intr.c: - Introduce support for registering/releasing MSI interrupts with Xen. - The MSI interrupts will use the same PIC as the IO APIC interrupts. xen/xen_msi.h: x86/xen/xen_msi.c: - Introduce a Xen MSI implementation. x86/xen/xen_nexus.c: - Overwrite the default MSI hooks in the Xen Nexus to use the Xen MSI implementation. x86/xen/xen_pci.c: - Introduce a Xen specific PCI bus that inherits from the ACPI PCI bus and overwrites the native MSI methods. - This is needed because when running under Xen the MSI messages used to configure MSI interrupts on PCI devices are written by Xen itself. dev/acpica/acpi_pci.c: - Lower the quality of the ACPI PCI bus so the newly introduced Xen PCI bus can take over when needed. conf/files.i386: conf/files.amd64: - Add the newly created files to the build process.
2014-09-30 18:46:45 +02:00
x86/xen/xen_msi.c optional xenhvm
xen: create a new PCI bus override When running as a Xen PVH Dom0 we need to add custom buses that override some of the functionality present in the ACPI PCI Bus and the PCI Bus. We currently override the ACPI PCI Bus, but not the PCI Bus, so add a new override for the PCI Bus and share the generic functions between them. Reported by: David P. Discher <dpd@dpdtech.com> Sponsored by: Citrix Systems R&D conf/files.amd64: - Add the new files. x86/xen/xen_pci_bus.c: - Generic file that contains the PCI overrides so they can be used by the several PCI specific buses. xen/xen_pci.h: - Prototypes for the generic overried functions. dev/xen/pci/xen_pci.c: - Xen specific override for the PCI bus. dev/xen/pci/xen_acpi_pci.c: - Xen specific override for the ACPI PCI bus.
2014-12-09 19:03:25 +01:00
x86/xen/xen_pci_bus.c optional xenhvm
Reference in New Issue Copy Permalink