nfs_nfsdsocket.c: All Copy and Clone across file systems
For some server file system types, such as ZFS, a Copy/Clone
operation can be done across file systems of the same file
system type.
As such, this patch allows the Copy/Clone to be attempted
when the file handles are for files on different file systems.
This fixes a problem for exported ZFS file systems when a
copy_files on file_range(2) between file systems in the same
NFSv4 mount is attempted.
PR: 294010
MFC after: 2 weeks
dup(2): document the handling of filedescriptor flags
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Differential revision: https://reviews.freebsd.org/D56121
diff3: set O_CLOEXEC on pipes
This avoid leaking pipe fd in children and simplifies the code
MFC After: 1 week
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D56120
Hyper-V: Detect Extended Destination ID support
Hyper-V advertises support for the Extended Destination ID standard via
bit 2 of the value returned in the EAX register when the hypervisor
stack properties are queried via CPUID.
This is based on a commit to the Linux kernel, as there does not seem
to be any other documentation of this feature.
Reviewed by: Souradeep Chakrabarti
MFC after: 3 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D55432
Bhyve: Detect Extended Destination ID support
Bhyve advertises support for the Extended Destination ID standard via
bit 0 (aka CPUID_BHYVE_FEAT_EXT_DEST_ID) of the value returned in the
EAX register when Bhyve features are queried via CPUID.
MFC after: 3 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D55431
vmm: Move defines from x86.c to x86/bhyve.h
The values CPUID_BHYVE_FEATURES and CPUID_BHYVE_FEAT_EXT_DEST_ID are
useful for guests, not just hosts; so they belong in a header file in
sys/x86/include rather than simply in the .c file implementing the
bhyve host side.
The original addition of these defines took place without adding a
copyright statement, but since I'm moving them into a new file I've
added the original author's standard copyright (Amazon).
MFC after: 3 weeks
Fixes: 313a68ea20b4 ("bhyve: Add CPUID_BHYVE_FEATURES leaf")
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D55430
Xen: Detect Extended Destination ID support
Xen advertises support for the Extended Destination ID standard via
bit 5 (aka XEN_HVM_CPUID_EXT_DEST_ID) of the value returned in the
EAX register when Xen features are queried via CPUID.
MFC after: 3 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D55429
KVM: Detect Extended Destination ID support
KVM advertises support for the Extended Destination ID standard via
bit 15 of the value returned in the EAX register when KVM features
are queried via CPUID.
Tested on: EC2 r8i.96xlarge
MFC after: 3 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D55427
io_apic: Support APIC Extended Destination IDs
If APIC Extended Destination ID support is enabled, use it in APIC RTEs
by allowing APIC IDs up to 2^15 - 1 and encoding the high bits into
Intel "reserved" bits per the standard.
Reviewed by: kib
MFC after: 3 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D55889
msi: Support APIC Extended Destination IDs
If APIC Extended Destination ID support is enabled, use it in MSIs by
allowing APIC IDs up to 2^15 - 1 and encoding the high bits into
Intel "reserved" bits per the standard.
Tested on: EC2 r8i.96xlarge
MFC after: 3 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D55426
x86: Add stub for Extended Destination ID support
Without an IOMMU, the APIC standard only allows 8 bits of Destination
ID for MSI messages, limiting us to 256 CPUs. While IOMMUs can allow
for more than 256 CPUs to be supported, they are not necessarily
desirable in virtualized environments.
The Extended Destination ID standard authored by David Woodhouse uses
7 "Reserved" bits for the high bits of a 15-bit Extended Destination
ID in order to address this: http://david.woodhou.se/ExtDestId.pdf
Add a loader tunable machdep.apic_ext_dest_id to control the use of
this feature; the default value (-1) means "autodetect" while 0 and
1 mean disabled and enabled respectively.
Code to detect host support in Xen, Hyper-V, KVM, and Bhyve will come
in future commits, as will the code to use this setting in msi_map and
ioapic_program_intpin.
[4 lines not shown]
io_apic: Don't route to APIC ID > 255
I/O APIC Redirection Table Entries use 8 bits to encode the Destination
ID. Attempting to route an IRQ to a higher APIC ID would result in it
being silently routed to the value reduced modulo 256, causing a panic
if the IRQ fired since the receiving CPU would not expect that IRQ.
Instead, print a warning and mark the interrupt as invalid, resulting
in it being forcibly masked.
Reviewed by: kib
Tested on: EC2 r8i.96xlarge
MFC after: 3 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D55857
x86: Add struct ioapic_intsrc.io_valid
As of this commit, io_valid is always set to 1; but a future commit
will set it to 0, at which point IOART_INTMSET will be set to forcibly
disable interrupt sources regardless of whether they are requested to
be "masked".
Reviewed by: kib
MFC after: 3 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D56006
clapic_handle_intr: KASSERT isrc != NULL
If an interrupt arrives at a CPU which isn't expecting that particular
vector, intr_lookup_source will return an isrc of NULL and we'll panic
when intr_execute_handlers increments *isrc->is_count.
Place a KASSERT a few nanoseconds earlier in order to leave some more
breadcrumbs for the next person to trip over this behaviour.
Tested on: EC2 r8i.96xlarge
MFC after: 3 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D55851
i386/amd64/NOTES: Add some missing devices
The following devices to x86: ocs_fc aq vge tws
And this to amd64: ufshci
These are in GENERIC, but not NOTES.
Sponsored by: Netflix
vmgenc: fix typo in MODULE_DEPEND declaration
The random_harvestq dependency was registered under the misspelled
name "vemgenc" instead of "vmgenc", causing the dependency to not
be associated with the correct module.
Signed-off-by: Christos Longros <chris.longros at gmail.com>
Reviewed by: cem, imp
Differential Revision: https://reviews.freebsd.org/D56012
routing: Retire ROUTE_MPATH compile option
The ROUTE_MPATH compile option was introduced to
test the new multipath implementation.
Since compiling it has no overhead and it's enabled
by default, remove it.
Reviewed by: melifaro, markj
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D55884
tests: Add grand link-layer event in netinet6/ndp
Add test for ndp to verity link-layer address change event
actually triggers the grand.
Differential Revision: https://reviews.freebsd.org/D55927
packages: Add dependency from rc to mtree
/etc/rc.d/var_run uses mtree, which is in the devel set and isn't
installed as part of either minimal or optional, so add a manual
dependency.
Reviewed by: des, bapt, emaste
Differential Revision: https://reviews.freebsd.org/D54540
Sponsored by: https://www.patreon.com/bsdivy
packages: Move xz to the minimal set
pkg(8), via its daily periodic script, requires xz. We don't have
a way to encode dependencies from ports on base packages right now,
so instead move xz to the minimal set so it's always installed.
This isn't an ideal solution, but it's justified in this case since
pkg(8) is always installed, so having its dependencies always
installed is acceptable.
(Following discusson on the diff, new versions of pkg have now been
changed to use zstd instead of xz, but we still think xz is useful
enough to keep in minimal.)
MFC after: 1 week (stable/15 only)
Reviewed by: des, bapt, emaste
Differential Revision: https://reviews.freebsd.org/D55630
Sponsored by: https://www.patreon.com/bsdivy
DEVICE_IDENTIFY.9: Fix function call to detect driver in example code
Fixes: ccabc7c2e556 ("DEVICE_IDENTIFY.9: Modernize description and use cases")
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
tests/netlink: Bugfix on snl_parse_errmsg_capped test
Turn off the NETLINK_EXT_ACK flag to fix bug of snl_parse_errmsg_capped.
Reviewed by: pouria
Pull Request: https://github.com/freebsd/freebsd-src/pull/1660
ix(4): Add EEE support for E610 adapters
The ix driver now supports Energy Efficient Ethernet (EEE) on Intel
E610 devices. EEE allows the network interface to enter low-power
states during periods of low link utilization, reducing power
consumption while maintaining full performance when needed.
E610 adapters provide EEE support through BASE-T PHY functionality.
Due to this PHY-based implementation, EEE is supported only
on 2.5Gb speeds and above.
Signed-off-by: Yogesh Bhosale <yogesh.bhosale at intel.com>
Signed-off-by: Krzysztof Galazka <krzysztof.galazka at intel.com>
Authored-by: Yogesh Bhosale <yogesh.bhosale at intel.com>
Approved by: kbowling (mentor)
Tested by: Mateusz Moga <mateusz.moga at intel.com>
Sponsored by: Intel Corporation
[3 lines not shown]
Revert superfluous mis-MFC of "Add ASMC_DEBUG make option"
Revert commit 12e1ab887d58 ("Add ASMC_DEBUG make option, 2026-01-04"),
as the original commit it intended to MFC has already been MFCed as
ab3eaa6ea29d846d on 2026/02/22 (UTC). The reverted commit introduced
some (superfluous) duplicate lines and an unrelated change.
This is a direct commit to stable/14.
Fixes: 12e1ab887d58 ("Add ASMC_DEBUG make option, 2026-01-04")
Sponsored by: The FreeBSD Foundation
uart/pci: support 16550A PCI serial devices
Expand the current check to also attach the ns8250 driver to devices
reporting as 16550A. This has been tested to work on a real device.
From an inspection of the code in the ns8250 driver it seems like it should
support up to 16950A devices, but I don't have hardware to ensure that,
hence be conservative with the change.
MFC: 2 weeks
Reviewed by: imp
Differential revision: https://reviews.freebsd.org/D56095
