Mark Johnston [Wed, 2 Sep 2020 18:16:43 +0000 (18:16 +0000)]
Include the psind in data returned by mincore(2).
Currently we use a single bit to indicate whether the virtual page is
part of a superpage. To support a forthcoming implementation of
non-transparent 1GB superpages, it is useful to provide more detailed
information about large page sizes.
The change converts MINCORE_SUPER into a mask for MINCORE_PSIND(psind)
values, indicating a mapping of size psind, where psind is an index into
the pagesizes array returned by getpagesizes(3), which in turn comes
from the hw.pagesizes sysctl. MINCORE_PSIND(1) is equal to the old
value of MINCORE_SUPER.
For now, two bits are used to record the page size, permitting values
of MAXPAGESIZES up to 4.
Reviewed by: alc, kib
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D26238
Mark Johnston [Wed, 2 Sep 2020 18:12:47 +0000 (18:12 +0000)]
Add the MEM_EXTRACT_PADDR ioctl to /dev/mem.
This allows privileged userspace processes to find information about the
physical page backing a given mapping. It is useful in applications
such as DPDK which perform some of their own memory management.
Further improve the drm2 deprecation message, only displaying information
about the port for relevant architectures, and skipping the message
completely from arm, which uses some parts of drm2 still.
This is mostly intended to be merged to 12, since the base bits of drm2 on
FreeBSD 13 are only really used on arm.
Reviewed by: manu, mmel
Approved by: manu
MFC after: 3 days
X-MFC-with: r364737
Differential Revision: https://reviews.freebsd.org/D26275
If the call to _pmap_allocpte() is not sleepable, it is possible that
allocation of PML4 or PDP page is successful but either PDP or PD page
is not. Restructured code in _pmap_allocpte() leaves zero-referenced
page in the paging structure.
Handle it by checking refcount of the page one level above failed
alloc and free that page if its reference count is zero.
Reported and tested by: pho
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D26293
The proper procedure was not followed in r364943; all of these that were
deleted should have instead been moved over to the blacklist so that certctl
can DTRT.
Users must still `certctl rehash` after this, but this should generally be
done by one of mergemaster/etcupdate/freebsd-update/pkgbase already; note
that freebsd-update doesn't come into play for this particular update, as
these have not yet made it into a release.
Future work (after svn -> git) will likely change the script that updatecert
invokes to facilitate the process, rather than trusting that kevans or
whomever updates in the future will remember.
Andrew Turner [Wed, 2 Sep 2020 11:53:26 +0000 (11:53 +0000)]
When CPUTYPE is an architecture name use -march
Allow architecture names to be passed in to the build system via CPUTYPE.
This allows the user to use values such as armv8.1-a or armv8-a+crc as
the CPUTYPE.
We must enter NET_EPOCH before calling ether_output_frame(). Several of the
functions it calls (pfil_run_hooks, if_transmit) expect to be running in the
NET_EPOCH.
While here remove an unneeded EPOCH entry (which wasn't wide enough to cover
BRIDGE_INPUT).
Micro optimise _callout_stop_safe() by removing dead code.
The CS_DRAIN flag cannot be set at the same time like the async-drain function
pointer is set. These are orthogonal features. Assert this at the beginning
of the function.
Before:
if (flags & CS_DRAIN) {
/* FALLTHROUGH */
} else if (xxx) {
return yyy;
}
if (drain) {
zzz = drain;
}
After:
if (flags & CS_DRAIN) {
/* FALLTHROUGH */
} else if (xxx) {
return yyy;
} else {
if (drain) {
zzz = drain;
}
}
Eric Joyner [Tue, 1 Sep 2020 23:16:38 +0000 (23:16 +0000)]
ixl(4): Add support for X710-T*L devices
Add support for new devices which are capable of 2.5 and 5G speeds, as well as
Energy Efficient Ethernet (EEE):
- introduce new device ids
- add ability to select 2.5 and 5G speeds on devices which support it
- add sysctls to enable EEE and read related statistics
Submitted by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Reviewed by: #IntelNetworking
MFC after: 3 days
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D25549