It has been pointed out, that this change causes ABI breakage for
[GP]IO_DEADKEYMAP. I'll create a review on phabricator.
Since the 8 bit limit on keycodes causes issues for certain keymaps,
a fix should be committed in time to allow a MFC to 13.2.
This reverts commit 1e0853ee84.
Reported by: Jessica Clarke
Exposing the a power loss of the rtc as an sysctl makes it easier to
detect an empty cmos battery.
Reviewed by: manu
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38325
Since mountd(8) will not be able to do exports
when running in a vnet prison if enforce_statfs is
set to 0, add a check for this to prison_check_nfsd().
Reviewed by: jamie, markj
MFC after: 2 months
Differential Revision: https://reviews.freebsd.org/D38189
When __thr_pshared_offpage() is called for allocation, it must not use
the cached offpage for the key. Instead, the cached offpage must be
unmapped and removed from the cache, if any.
It is legitimate for the user code to unmap the shared lock object without
destroying it, and then mapping something over the freed VA to carry
another shared lock. In this case the cached offpage must be un-cached.
PR: 269277
Reported by: rau8344@gmail.com
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D38345
Jumping direct to ret was not restoring the saved value of x19 and was
also not adjusting sp to discard the two saved registers.
Reviewed by: andrew
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D37922
This somewhat undermines the initial goal of sousrsend() to have all
the special error handling for a write on a socket in a single place.
The aio(4) needs to see EWOULDBLOCK to re-schedule the job. Because
aio(4) handles return from soreceive() and sousrsend() with the same
code, we can't check for (error == 0 && done < job_nbytes). Keeping
this exclusion for aio(4) seems a lesser evil.
Fixes: 7a2c93b86e
Remove the hard-coded dependency on HYPERV being only x86. Instead, 100%
rely on MK_HYPERV. It's always right (since it's marked BROKEN (so set
to "no") on architectures we don't support).
Sponsored by: Netflix
Reviewed by: bz
Differential Revision: https://reviews.freebsd.org/D38306
This patch does remaining enablement in hyperv vpci driver to work
on arm64 Hyper-V. For that it required to use PCI protocol 1.4 and
corresponding different PCI message handling. Also new MSI allocation,
MSI-X mapping, release.
This is the last patch of total three patches to enalbe Hyper-V vPCI
support in arm64.
Reviewed by: whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Obtained from: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D37958
Some keyboard definitions return Unicode characters that cannot be
represented in the 8 bits provided by an u_char.
Extend then width of the keycode entries to 16 bits to allow for all
keycodes currently defined in share/vt/keymaps/*,kbd.
Reported by: yuri@aetern.org
MFC after: 3 days
This is enabling the PCI protocol 1.4 and corresponding structures
in order to support arm64 Hyper-V.
This is the 2nd of the three patches to enable Hyper-V vPCI support
in arm64.
Reviewed by: whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Obtained from: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D37780
Microsoft Azure Hyper-V uses SPI to map MSI in ARM64, instead of
using LPI IDS. To enable that we need to have gic registered with
ACPI_MSI_XREF and gic acpi to map SPI for MSI.
This is the 1st of the three patchs to enable Hyper-V vPCI support
in arm64.
Reviewed by: andrew, emaste, whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Obtained from: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D37763
A vcpu only checks if a rendezvous is in progress or not to decide if it
should handle a rendezvous. This could lead to spurios rendezvous where
a vcpu tries a handle a rendezvous it isn't part of. This situation is
properly handled by vm_handle_rendezvous but it could potentially
degrade the performance. Avoid that by an early check if the vcpu is
part of the rendezvous or not.
At the moment, rendezvous are only used to spin up application
processors and to send ioapic interrupts. Spinning up application
processors is done in the guest boot phase by sending INIT SIPI
sequences to single vcpus. This is known to cause spurious rendezvous
and only occurs in the boot phase. Sending ioapic interrupts is rare
because modern guest will use msi and the rendezvous is always send to
all vcpus.
Reviewed by: jhb
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37390
Add code (currently disabled by #ifdef) for HT and VHT to
lkpi_scan_ies_add(). Switch to a local variable for ic given
the new code also needs the value.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
This change breaks the API of `list_sort()`. `LINUXKPI_VERSION >= 51300`
is used to keep the header compatible with both versions of the
prototype.
Reviewed by: manu
Approved by: manu
Differential Revision: https://reviews.freebsd.org/D38082
Observed on a couple Ice Lake-SP platforms (Intel Coyote Pass, Dell
R750), there are more than 8 DRHD sections enumerated in the DMAR ACPI
section. Since the previous limit was 8, this resulted in some of these
not being parsed by vtd when the iommu is initialized; in this case when
PCI devices are being passthru'd to a bhyve VM.
This omission later causes a kernel panic later in initialization when
devices could not be found in a valid DRHD scope because the DHRD
containing the device's scope was not added to vtd.
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
PR: 268486
Sponsored by: Intel Corporation
Reviewed by: rew@, corvink@
MFC after: 1 day
Differential Revision: https://reviews.freebsd.org/D38285
Summary:
The only user of the ALTQ_IS_ENABLED() in a driver checks against the
ifnet queue. Abstract that all out and present the interface to check
if ALTQ is enabled on the interface.
Sponsored by: Juniper Networks, Inc.
Reviewed By: glebius
Differential Revision: https://reviews.freebsd.org/D38204
Summary:
Firewire is the only device driver that accesses the l2com member, all
other accesses are handled within the netstack itself.
Sponsored by: Juniper Networks, Inc.
Reviewed by: glebius, melifaro
Differential Revision: https://reviews.freebsd.org/D38203
Summary:
* if_setreassignfn for wireguard.
* if_getinputfn() and if_getstartfn() for various drivers. Use the
function descriptor typedefs for these and the setters.
* vlantrunk accessor. This is used by VLAN_CAPABILITIES() used by
several drivers, as well as directly by mxge(4).
* if_pcp member accessor, used by cxgbe.
* accessors for netmap adapter.
Sponsored by: Juniper Networks, Inc.
Reviewed By: glebius
Differential Revision: https://reviews.freebsd.org/D38202
Summary:
Keep TOEDEV() macro for backwards compatibility, and add a SETTOEDEV()
macro to complement with the new accessors.
Sponsored by: Juniper Networks, Inc.
Reviewed by: glebius
Differential Revision: https://reviews.freebsd.org/D38199
