Import an optimized str{n}cmp on arm64

These are from the Arm Optimized Routines and don't use the VFP so are
safe to use in the kernel.

Sponsored by: The FreeBSD Foundation

x86: remove MP_WATCHDOG

It does not work with ULE, which is the default scheduler for over a
decade.

Reviewed by: emaste, kib
Differential Revision: https://reviews.freebsd.org/D36094

qat: Rename to qat_c2xxx and remove support for modern chipsets

A replacement QAT driver will be imported, but this replacement does not
support Atom C2xxx hardware. So, the existing driver will be

qat: Rename to qat_c2xxx and remove support for modern chipsets

A replacement QAT driver will be imported, but this replacement does not
support Atom C2xxx hardware. So, the existing driver will be kept
around to provide opencrypto offload support for those chipsets.

Reviewed by: pauamma, emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35817

show more ...

isci: Disable set but unused warnings.

x86/apic: remove apic_ops

All supported Xen instances by FreeBSD provide a local APIC
implementation, so there's no need to replace the native local APIC
implementation anymore.

Leave just the ipi_

x86/apic: remove apic_ops

All supported Xen instances by FreeBSD provide a local APIC
implementation, so there's no need to replace the native local APIC
implementation anymore.

Leave just the ipi_vectored hook in order to be able to override it
with an implementation based on event channels if the underlying local
APIC is not virtualized by hardware. Note the hook cannot use ifuncs,
because at the point where ifuncs are resolved the kernel doesn't yet
know whether it will benefit from using the optimization.

Sponsored by: Citrix Systems R&D
Reviewed by: kib
Differential revision: https://reviews.freebsd.org/D33917

show more ...

pchtherm: Let the driver be compiled into the kernel

PR: 259776
MFC after: 1 week

Retire synchronous PPP kernel driver sppp(4).

The last two drivers that required sppp are cp(4) and ce(4).

These devices are still produced and can be purchased
at Cronyx <http://cronyx.ru/hardware

Retire synchronous PPP kernel driver sppp(4).

The last two drivers that required sppp are cp(4) and ce(4).

These devices are still produced and can be purchased
at Cronyx <http://cronyx.ru/hardware/wan.html>.

Since Roman Kurakin <rik@FreeBSD.org> has quit them, they no
longer support FreeBSD officially. Later they have dropped
support for Linux drivers to. As of mid-2020 they don't even
have a developer to maintain their Windows driver. However,
their support verbally told me that they could provide aid to
a FreeBSD developer with documentaion in case if there appears
a new customer for their devices.

These drivers have a feature to not use sppp(4) and create an
interface, but instead expose the device as netgraph(4) node.
Then, you can attach ng_ppp(4) with help of ports/net/mpd5 on
top of the node and get your synchronous PPP. Alternatively
you can attach ng_frame_relay(4) or ng_cisco(4) for HDLC.
Actually, last time I used cp(4) back in 2004, using netgraph(4)
instead of sppp(4) was already the right way to do.

Thus, remove the sppp(4) related part of the drivers and enable
by default the negraph(4) part. Further maintenance of these
drivers in the tree shouldn't be a big deal.

While doing that, remove some cruft and enable cp(4) compilation
on amd64. The ce(4) for some unknown reason marks its internal
DDK functions with __attribute__ fastcall, which most likely is
safe to remove, but without hardware I'm not going to do that, so
ce(4) remains i386-only.

Reviewed by: emaste, imp, donner
Differential Revision: https://reviews.freebsd.org/D32590
See also: https://reviews.freebsd.org/D23928

show more ...

x86: duplicate acpi_wakeup.c per i386 and amd64

The file as is is the maze of #ifdef passages, all slightly different.
Divorcing i386 and amd64 version actually makes changing the code
easier, also

x86: duplicate acpi_wakeup.c per i386 and amd64

The file as is is the maze of #ifdef passages, all slightly different.
Divorcing i386 and amd64 version actually makes changing the code
easier, also no changes for i386 are planned.

Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D31931

show more ...

Microsoft Azure Network Adapter(MANA) VF support

MANA is the new network adapter from Microsoft which will be available
in Azure public cloud. It provides SRIOV NIC as virtual function to
guest OS r

Microsoft Azure Network Adapter(MANA) VF support

MANA is the new network adapter from Microsoft which will be available
in Azure public cloud. It provides SRIOV NIC as virtual function to
guest OS running on Hyper-V.

The code can be divided into two major parts. Gdma_main.c is the one to
bring up the hardware board and drives all underlying hardware queue
infrastructure. Mana_en.c contains all main ethernet driver code.
It has only tested and supported on amd64 architecture.

PR: 256336
Reviewed by: decui@microsoft.com
Tested by: whu
MFC after: 2 week
Relnotes: yes
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D31150

show more ...

kvm_clock: KVM paravirtual clock support

Add support for the KVM paravirtual clock device.

Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: kib
Differential Revision: htt

kvm_clock: KVM paravirtual clock support

Add support for the KVM paravirtual clock device.

Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D29733

show more ...

x86: files: Make sys/x86/x86/pvclock.c optional

Make inclusion of `sys/x86/x86/pvclock.c` contingent on that of its
dependents.

Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Review

x86: files: Make sys/x86/x86/pvclock.c optional

Make inclusion of `sys/x86/x86/pvclock.c` contingent on that of its
dependents.

Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D31417

show more ...

xen: move x86/xen/xenpv.c to dev/xen/bus/xenpv.c

Minor changes are necessary to make this processor-independent, but
moving the file out of x86 and into common is the first step (so
others don't add

xen: move x86/xen/xenpv.c to dev/xen/bus/xenpv.c

Minor changes are necessary to make this processor-independent, but
moving the file out of x86 and into common is the first step (so
others don't add /more/ x86-isms).

Submitted by: Elliott Mitchell <ehem+freebsd@m5p.com>
Reviewed by: royger
Differential Revision: https://reviews.freebsd.org/D29042

show more ...

linux(4): Get rid of Linuxulator kernel build options.

Stop confusing people, retire COMPAT_LINUX and COMPAT_LINUX32 kernel
build options. Since we have 32 and 64 bit Linux emulators, we can't build

linux(4): Get rid of Linuxulator kernel build options.

Stop confusing people, retire COMPAT_LINUX and COMPAT_LINUX32 kernel
build options. Since we have 32 and 64 bit Linux emulators, we can't build both
emulators together into the kernel. I don't think it matters, Linux emulation
depends on loadable modules (via rc).

Cut LINPROCFS and LINSYSFS for consistency.

PR: 215061
Reviewed by: bcr (manpages), trasz
Differential Revision: https://reviews.freebsd.org/D30751
MFC after: 2 weeks

show more ...

x86/xen: remove PVHv1 code

PVHv1 was officially removed from Xen in 4.9, so just axe the related
code from FreeBSD.

Note FreeBSD supports PVHv2, which is the replacement for PVHv1.

Sponsored by: C

x86/xen: remove PVHv1 code

PVHv1 was officially removed from Xen in 4.9, so just axe the related
code from FreeBSD.

Note FreeBSD supports PVHv2, which is the replacement for PVHv1.

Sponsored by: Citrix Systems R&D
Reviewed by: kib, Elliott Mitchell
Differential Revision: https://reviews.freebsd.org/D30228

show more ...

hptrr: Move to using .o files

Use .o files directly. Replace the .o.uu files that we uudecode with .o files.
Adjust the kernel and module build to cope.

Suggestions by: markj@, emaste@
Sposnored b

hptrr: Move to using .o files

Use .o files directly. Replace the .o.uu files that we uudecode with .o files.
Adjust the kernel and module build to cope.

Suggestions by: markj@, emaste@
Sposnored by: Netflix, Inc
Differential Revision: https://reviews.freebsd.org/D29636

show more ...

hptmv: use .o files directly

uudecode the .o.uu files and commit directly to the tree. Adjust the build
infrastructure to cope with the new location, both for the kernel and modules.

Sposnored by:

hptmv: use .o files directly

uudecode the .o.uu files and commit directly to the tree. Adjust the build
infrastructure to cope with the new location, both for the kernel and modules.

Sposnored by: Netflix, Inc
Differential Revision: https://reviews.freebsd.org/D29635

show more ...

hpt27xx: store the .o files directly in the tree

Store the .o files directly in the tree. We no longer need to play uuencode
games like we did in the CVS days. Adjust the build infrastructure to mat

hpt27xx: store the .o files directly in the tree

Store the .o files directly in the tree. We no longer need to play uuencode
games like we did in the CVS days. Adjust the build infrastructure to match.

Reviewed by: markj@
Sposnored by: Netflix, Inc
Differential Revision: https://reviews.freebsd.org/D29634

show more ...

hptnr: Store the .o files directly in the repo

We no longer need to use uuencode to uuencode files in our tree. Store the .o
file directly instead. Adjust the build to cope with the new arrangement

hptnr: Store the .o files directly in the repo

We no longer need to use uuencode to uuencode files in our tree. Store the .o
file directly instead. Adjust the build to cope with the new arrangement.

Suggestions by: emaste, bz, donner
Reviewed by: markm
Sposnored by: Netflix, Inc
Differential Revision: https://reviews.freebsd.org/D29632

show more ...

x86: remove gcov kernel support

Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D29529

gdb: allow setting/removing hardware watchpoints

Handle the 'z' and 'Z' remote packets for manipulating hardware
watchpoints.

This could be expanded quite easily to support hardware or software
bre

gdb: allow setting/removing hardware watchpoints

Handle the 'z' and 'Z' remote packets for manipulating hardware
watchpoints.

This could be expanded quite easily to support hardware or software
breakpoints as well.

https://sourceware.org/gdb/onlinedocs/gdb/Packets.html

Reviewed by: cem, markj
MFC after: 3 weeks
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
NetApp PR: 51
Differential Revision: https://reviews.freebsd.org/D29173

show more ...

x86: consolidate hw watchpoint logic into new file

This is a prerequisite to using these functions outside of ddb, but also
provides some cleanup and minor refactoring. This code is almost
entirely

x86: consolidate hw watchpoint logic into new file

This is a prerequisite to using these functions outside of ddb, but also
provides some cleanup and minor refactoring. This code is almost
entirely duplicated between the two implementations, the only
significant difference being the lack of dbreg synchronization on i386.

Cleanups are:
- demote some internal functions to static
- use the constant NDBREGS instead of a '4' literal
- remove K&R definitions
- some added comments

Reviewed by: kib, jhb
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D29153

show more ...

smbios: Move smbios driver out from x86 machdep code

Add it to the x86 GENERIC and MINIMAL kernels

Sponsored by: Ampere Computing LLC
Submitted by: Klara Inc.
Reviewed by: rpokala
Differential Revi

smbios: Move smbios driver out from x86 machdep code

Add it to the x86 GENERIC and MINIMAL kernels

Sponsored by: Ampere Computing LLC
Submitted by: Klara Inc.
Reviewed by: rpokala
Differential Revision: https://reviews.freebsd.org/D28738

show more ...

ndis(4): remove as previous announced

nids(4) was a clever idea in the early 2000's when the market was
flooded with 10/100 NICs with Windows-only drivers, but that hasn't been
the case for ages and

ndis(4): remove as previous announced

nids(4) was a clever idea in the early 2000's when the market was
flooded with 10/100 NICs with Windows-only drivers, but that hasn't been
the case for ages and the driver has had no meaningful maintenance in
ages. It only supports Windows-XP era drivers.

Also remove:
- ndis support from wpa_supplicant
- ndiscvt(8)

Reviewed By: emaste, bcr (manpages)
Differential Revision: https://reviews.freebsd.org/D27609

show more ...

pccard: Remove if_ndis(4) PC Card attachment

PC Card support is being removed, so remove its attachment here. ndis
is slated to be removed entirely for 13, but that's not been done yet.

Relnotes: Y

pccard: Remove if_ndis(4) PC Card attachment

PC Card support is being removed, so remove its attachment here. ndis
is slated to be removed entirely for 13, but that's not been done yet.

Relnotes: Yes

show more ...

pccard: Remove fdc(4) PC Card attachment point

Remove PC Card attachemnt point for fdc.

Relnotes: Yes