MFH: Tracking commit (r260891)

Sponsored by: The FreeBSD Foundation

Add very simple virtio_random(4) driver to harvest entropy from host

Reviewed by: markm (random bits only)

Support Hyper-V on i386:

- Add 'hyperv' module into build;
- Allow building Hyper-V support as part of the kernel;
- Hook Hyper-V build into NOTES.

This is intended for MFC if re@ permits.

MFC

Support Hyper-V on i386:

- Add 'hyperv' module into build;
- Allow building Hyper-V support as part of the kernel;
- Hook Hyper-V build into NOTES.

This is intended for MFC if re@ permits.

MFC after: 3 days

show more ...

Merge head r232040 through r257457.
M usr.sbin/portsnap/portsnap/portsnap.8
M usr.sbin/portsnap/portsnap/portsnap.sh
M usr.sbin/tcpdump/tcpdump/Makefile

MFC @ r256071

This is just prior to the bhyve_npt_pmap import so will allow
just the change to be merged for easier debug.

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

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

show more ...

Merge head r233826 through r256722.

Merge head@256284

IFC @256277

Approved by: ken (mentor)

MFC- tracking commit.

add aesni module to i386 and amd64 NOTES...

Approved by: re (gjb)

MFC - tracking update.

Substantial rewrite of bxe(4) to add support for the BCM57712 and
BCM578XX controllers.

Approved by: re
MFC after: 4 weeks

IFC @ r255692

Comment out IA32_MISC_ENABLE MSR access - this doesn't exist on AMD.
Need to sort out how arch-specific MSRs will be handled.

Merge head

IFC @ r255459

MFC

Add vmx device to the i386 and amd64 NOTES files

Merge from head

IFC @ r255209

IFC.

The PADLOCK_RNG and RDRAND_RNG kernel options are now devices.
Thus "device padlock_rng" and "device rdrand_rng" should be
used instead of "options PADLOCK_RNG" & "options RDRAND_RNG".

Requested by:

The PADLOCK_RNG and RDRAND_RNG kernel options are now devices.
Thus "device padlock_rng" and "device rdrand_rng" should be
used instead of "options PADLOCK_RNG" & "options RDRAND_RNG".

Requested by: so@ (des)
Submitted by: obrien, arthurmesh@gmail.com
Obtained from: Juniper Networks

show more ...

IFC @ r254014

IFC @ r253461

IFC @253398