r346313 emaste April 17, 2019, 3:48 p.m.
Submitted by:	Bora Özarslan" <borako.ozarslan@gmail.com>
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
r346312 ian April 17, 2019, 3:27 p.m.
The code previously set up interrupt handlers for all the interrupt
resources available, including for timers that are not in use.  That could
lead to interrupt storms.  For example, if boot firmware enabled the virtual
timer but the kernel is using the physical timer, it could get flooded with
interrupts on the virtual timer which it cannot shut off.  By only setting
up an interrupt handler for the hardware that will actually be used, any
interrupts from other timer units will remain masked in the interrupt

Differential Revision:	https://reviews.freebsd.org/D19871
r346311 pfg April 17, 2019, 2:20 p.m.
r346310 pfg April 17, 2019, 2:12 p.m.
Approved by: pfg (mentor)
r346307 kevans April 17, 2019, 3:29 a.m.
FDT_DTS_FILE was built separately with a rule in sys/conf/files and
recreated the rules we used in dtb.mk. Now that we have other infrastructure
to build a DTB along with the kernel, fold FDT_DTS_FILE into that since it
doesn't have any special requirements.

fdt(4) never got revised to mention the DTS/DTSO make options, so do that

Reviewed by:	imp
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D19736
r346305 manu April 16, 2019, 10:42 p.m.
MFC after:	2 weeks
r346299 emaste April 16, 2019, 8:41 p.m.
isc_rxd_refill, isc_rxd_flush return nothing, not void *.

isc_txd_credits_update, isc_rxd_available return int, not int *.

isc_txd_credits_update has a bool as final argument, not a uint32_t.
Prior to r315217 it took four arguments; the final two were
uint32_t, bool.

Reported by:	Gerald Aryeetey <aryeeteygerald_rogers.com>
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
r346298 manu April 16, 2019, 8:08 p.m.
This is useful for arm (possibly other arches too) where we want to have
a GENERIC kernel that only include files for the different SoC. Since
multiple SoCs/Board needs the same device we would need to do either :

    Include the device in a generic file
    Include the device in each file that really needs it

Option 1 works but if someone wants to create a specific kernel config
(which isn't uncommon for embedded system), he will need to add a lots
of nodevice to it.

Option 2 also works but produce a lots of warnings.

Reviewed by:	kevans
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D19424
r346297 manu April 16, 2019, 8:06 p.m.
MFC after:	2 weeks
r346295 manu April 16, 2019, 8:04 p.m.
This files is needed and included in all our config so move it to a common

MFC after:	2 weeks
r346294 kib April 16, 2019, 7:46 p.m.
After the referenced commit, we did not set x87 and sse valid bits in
the xstate_bv bitmask for initial fpu state (stored in memory), when
using XSAVE.

The state is loaded into FPU register file to initialize the process
FPU state, and since both bits were clear, the default x87 and SSE
states were loaded.  By chance, FreeBSD ABI SSE2 state is same as FPU
initial state, so the bug is not visible for 64bit processes.  But on
i386, the precision control should be set to double (53bit mantissa),
instead of the default double extended (64bit mantissa). For 32bit
processes on amd64, kernel reloads control word with the right mask,
which only left native i386 and amd64 native but using x87 as

Fix it by setting minimal required xstate_bv mask.

Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
r346293 manu April 16, 2019, 7:38 p.m.
The old clocks are disconneted from the build since r337344.
Remove all those pseudo drivers. The only one remaining is for gmac
(the ethernet controller) so move it to sys/arm/allwinner.
While here remove a83t support from gmacclk as it is unneeded since r326114.

MFC after:	1 month
r346292 cem April 16, 2019, 6:47 p.m.
This is a stopgap measure to unbreak installer/VM/embedded boot issues
introduced (or at least exposed by) in r346250.

Add the new tunable, "security.stack_protect.permit_nonrandom_cookies," in
order to continue boot with insecure non-random stack cookies if the random
device is unavailable.

For now, enable it by default.  This is NOT safe.  It will be disabled by
default in a future revision.

There is follow-on work planned to use fast random sources (e.g., RDRAND on
x86 and DARN on Power) to seed when the early entropy file cannot be
provided, for whatever reason.  Please see D19928.

Some better hacks may be used to make the non-random __stack_chk_guard
slightly less predictable (from delphij@ and mjg@); those suggestions are
left for a future revision.  I think it may also be plausible to move stack
guard initialization far later in the boot process; potentially it could be
moved all the way to just before userspace is started.

Reported by:	many
Reviewed by:	delphij, emaste, imp (all w/ caveat: this is a stopgap fix)
Security:	yes
Sponsored by:	Dell EMC Isilon
Differential Revision:	https://reviews.freebsd.org/D19927
r346282 cem April 16, 2019, 5:12 p.m.
The imagined use is for early boot consumers of random to be able to make
decisions based on whether random is available yet or not.  One such
consumer seems to be __stack_chk_init(), which runs immediately after random
is initialized.  A follow-up patch will attempt to address that.

Reported by:	many
Reviewed by:	delphij (except man page)
Approved by:	secteam(delphij)
Differential Revision:	https://reviews.freebsd.org/D19926
r346281 gallatin April 16, 2019, 4:49 p.m.
The cosqos field was added nearly 6 years ago in r254804, and it is
still unused by any in-tree consumers.  I have a patchset that I'm
working on which aligns many network resources by NUMA domain,
including inps, inpcb lb group, tcp pacing, lagg output link
selection, backing pages for sendfile, and more.  It reduces
cross-domain traffic by roughly 50% for a real web workload.

This patchset relies on being able to store the numa domain in the
mbuf, and grabbing the unused cosqos field for this purpose is the
first step in starting to usptream it.

Reviewed by:	kib, markj
Sponsored by:	Netflix
Differential Revision:	https://reviews.freebsd.org/D19862