6aee0bfa zec June 19, 2019, 8:39 a.m. 
at runtime.  This change removes a dependency on a barrel shifter pass
before branch resolution, while reducing the instruction stream size
by 9 bytes on amd64.

MFC after:	3 days
cgit ViewVC
da761f3b scottl June 19, 2019, 6:41 a.m. 
translation units with differing capabilities

From the author via Bugzilla:
---
When an attempt is made to passthrough a PCI device to a bhyve VM
(causing initialisation of IOMMU) on certain Intel chipsets using
VT-d the PCI bus stops working entirely. This issue occurs on the
E3-1275 v5 processor on C236 chipset and has also been encountered
by others on the forums with different hardware in the Skylake
series.

The chipset has two VT-d translation units. The issue is caused by
an attempt to use the VT-d device-IOTLB capability that is
supported by only the first unit for devices attached to the
second unit which lacks that capability. Only the capabilities of
the first unit are checked and are assumed to be the same for all
units.

Attached is a patch to rectify this issue by determining which
unit is responsible for the device being added to a domain and
then checking that unit's device-IOTLB capability. In addition to
this a few fixes have been made to other instances where the first
unit's capabilities are assumed for all units for domains they
share. In these cases a mutual set of capabilities is determined.
The patch should hopefully fix any bugs for current/future
hardware with multiple translation units supporting different
capabilities.

A description is on the forums at
https://forums.freebsd.org/threads/pci-passthrough-bhyve-usb-xhci.65235
The thread includes observations by other users of the bug
occurring, and description as well as confirmation of the fix.
I'd also like to thank Ordoban for their help.

---
Personally tested on a Skylake laptop, Skylake Xeon server, and
a Xeon-D-1541, passing through XHCI and NVMe functions.  Passthru
is hit-or-miss to the point of being unusable without this
patch.

PR: 229852
Submitted by: callum@aitchison.org
MFC after: 1 week
cgit ViewVC
0b3c5f1b alc June 19, 2019, 3:33 a.m. 
count, not its resident count.

X-MFC with:	r349122
cgit ViewVC
46dea205 bdrewery June 18, 2019, 10 p.m. 
This is still targeting bin/sh cyclic dependency issues.  Only apply
guessed dependencies that are explicitly set for an object (which
gnu/lib/cc/cc_tools needs) and if no custom target exists with its
own dependencies.

This was manifesting as a missing yacc.h in usr.bin/mkesdb_static when
built without -j (or -B). No actual yacc.h dependency ordering was
defined but with -j it got lucky and built fine.

Before r349061 the behavior was different for META_MODE but that logic
difference isn't needed.

X-MFC-With:	r349061
Sponsored by:	DellEMC
cgit ViewVC
5c32e9fc mav June 18, 2019, 9:05 p.m. 
On large systems those sysctls may generate megabytes of output.  Before
this change sbuf(9) code was resizing buffer by 4KB each time many times,
generating tons of TLB shootdowns.  Unfortunately in this case existing
sbuf_new_for_sysctl() mechanism, supposed to help with this issue, is not
applicable, since all the sbuf writes are done in different kernel thread.

This change improves situation in two ways:
 - on first sysctl call, not providing any output buffer, it sets special
sbuf drain function, just counting the data and so not needing big buffer;
 - on second sysctl call it uses as initial buffer size value saved on
previous call, so that in most cases there will be no reallocation, unless
GEOM topology changed significantly.

MFC after:	1 week
Sponsored by:	iXsystems, Inc.
cgit ViewVC
cfdcc8c7 sevan June 18, 2019, 9:02 p.m. 
NetBSD 7.0 was a separate branch, subsequent 8.x releases did not emerge from
this branch.
Clean up minor visual nits, centre OpenBSD listing on the B, DragonFly
listings on the y.
cgit ViewVC
22eedc97 cem June 18, 2019, 6:50 p.m. 
In r349154, random device reads of size < 16 bytes (AES block size) were
accidentally broken to loop forever.  Correct the loop condition for small
reads.

Reported by:	pho
Reviewed by:	delphij
Approved by:	secteam(delphij)
Differential Revision:	https://reviews.freebsd.org/D20686
cgit ViewVC
5c2b348a vmaffione June 18, 2019, 5:51 p.m. 
The vsc_rx_ready and the RX virtqueue is protected by the rx_mtx lock.
However, pci_vtnet_ping_rxq() (currently called only once after each
device reset) accesses those without acquiring the lock.

Reviewed by:	markj
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D20609
cgit ViewVC
edd96b9f ian June 18, 2019, 5:05 p.m. 
easiest thing for a user to control (via loader.conf or kenv+kldload), so
handle them in addition to any label specified via the FDT data.
cgit ViewVC
05918954 emaste June 18, 2019, 2:13 p.m. 
In all supported (and most unsupported) FreeBSD versions the appropriate
header for Capsicum is sys/capsicum.h.  Software including sys/capability.h
is most likely looking for Linux capabilities based on the withdrawn
POSIX.1e draft.

This header was previously removed in r334929 and r340156, but reverted
each time due to ports failures.  These issues have now (broadly) been
addressed.

PR:		228878 [exp-run]
Submitted by:	eadler (r334929)
Relnotes:	Yes
Sponsored by:	The FreeBSD Foundation
cgit ViewVC
a161bab8 ian June 18, 2019, 4:32 a.m.
0309916a ian June 18, 2019, 2:27 a.m. 
Reported by:	rpokala@
cgit ViewVC
26f3ca61 ian June 18, 2019, 1:15 a.m. 
can be combined with configuring the period and duty cycle (the same ioctl
sets all 3 values at once, so there's no reason to require the user to run
the program twice to get all 3 things set).
cgit ViewVC
123570fb ian June 18, 2019, 12:17 a.m. 
pwmc(4) device filenames.  Also, use uppercase PWM when the term is being
used as an acronym, and expand the acronym where it's first used.
cgit ViewVC
780c3de8 ian June 18, 2019, 12:11 a.m. 
that there is a pwmc(4) instance per channel and the channel number is
maintained as a driver ivar rather than being passed in from userland.
cgit ViewVC