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
x11/nvidia-driver, x11/nvidia-kmod, x11/linux-nvidia-libs, graphics/nvidia-drm*-kmod, x11/nvidia-settings, x11/nvidia-xconfig: Update to 595.58.03
Update to latest Production Branch of drivers 595.58.03:
https://www.nvidia.com/en-us/drivers/details/265873/
Linux counterparts for x11/linux-nvidia-libs:
https://www.nvidia.com/en-us/drivers/details/265870/
Also bump -devel variant to match with master ports, as Production
Branch [PB] of drivers have now higher version than New Feature
Branch [NFB] of drivers.
As this update drops a bunch of old (pre-Turing generation of
architectures) GPUs as done in -devel variants updated 20260103,
add -580 variant of legacy branch of driver.
Currently, this is exactly the same version before this update.
(580.142)
[2 lines not shown]
www/fabio: Update 1.6.4 => 1.6.11, fix runtime
A recent update to Consul causes Fabio to fail to register itself in the
service directory. Consul has apparently become stricter in its
interpretation of IPv4 addresses and fails to recognize an IPv4 address
surrounded by square brackets. Versions prior to 1.22 permitted this.
Fabio (prior to 1.6.11) sends its IPv4 address wrapped in square
brackets and will fail to register on a newer Consul.
Changelog:
https://github.com/fabiolb/fabio/blob/master/CHANGELOG.md#v1611-2025-12-09
While here replace PORTVERSION with DISTVERSION.
PR: 294048
Approved by: blanket (fix runtime)
Sponsored by: UNIS Labs
MFH: 2026Q1
