6d5586da pho March 22, 2021, 10:26 a.m.
74ada297 khng March 22, 2021, 9:33 a.m.
Currently, AMD-vi PCI-e passthrough will lead to the following lines in
"kernel: CPU0: local APIC error 0x40
ivhd0: Error: completion failed tail:0x720, head:0x0."

After some tracing, the problem is due to the interaction with
amdvi_alloc_intr_resources() and pci_driver_added(). In ivrs_drv, the
identification of AMD-vi IVHD is done by walking over the ACPI IVRS
table and ivhdX device_ts are added under the acpi bus, while there are
no driver handling the corresponding IOMMU PCI function. In
amdvi_alloc_intr_resources(), the MSI intr are allocated with the ivhdX
device_t instead of the IOMMU PCI function device_t. bus_setup_intr() is
called on ivhdX. the IOMMU pci function device_t is only used for
pci_enable_msi(). Since bus_setup_intr() is not called on IOMMU pci
function, the IOMMU PCI function device_t's dinfo->cfg.msi is never
updated to reflect the supposed msi_data and msi_addr. So the msi_data
and msi_addr stay in the value 0. When pci_driver_added() tried to loop
over the children of a pci bus, and do pci_cfg_restore() on each of
them, msi_addr and msi_data with value 0 will be written to the MSI
capability of the IOMMU pci function, thus explaining the errors in

This change includes an amdiommu driver which currently does attaching,
detaching and providing DEVMETHODs for setting up and tearing down
interrupt. The purpose of the driver is to prevent pci_driver_added()
from calling pci_cfg_restore() on the IOMMU PCI function device_t.
The introduction of the amdiommu driver handles allocation of an IRQ
resource within the IOMMU PCI function, so that the dinfo->cfg.msi is

This has been tested on EPYC Rome 7282 with Radeon 5700XT GPU.

Sponsored by:	The FreeBSD Foundation
Reviewed by:	jhb
Approved by:	philip (mentor)
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D28984
ede14736 khng March 22, 2021, 9:33 a.m.
Reviewed by:	jhb
Approved by:	philip (mentor)
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D28945
25bfa448 adrian March 22, 2021, 12:02 a.m.
* device_printf() is effectively a printf
* if_printf() is effectively a LOG_INFO

This allows subsystems to log device/netif stuff using different log levels,
rather than having to invent their own way to prefix unit/netif  names.

Differential Revision: https://reviews.freebsd.org/D29320
Reviewed by: imp
2595d78f kbowling March 21, 2021, 6:55 p.m.
Approved by:	cognet
MFC after:	1 week
Sponsored by:	BBOX.io
Differential Revision:	https://reviews.freebsd.org/D29357
1af332a7 markj March 21, 2021, 6:19 p.m.
The header specifies the size of the option in multiples of eight bytes.
The option consists of an eight-byte header followed by one or more IPv6
addresses, so the option is invalid if the size is not equal to 1+2n for
some n>0.  Check this.

The bug can cause random stack data to be formatted as an IPv6 address
and passed to resolvconf(8), but a host able to trigger the bug may also
specify arbitrary addresses this way.

Reported by:	Q C <cq674350529@gmail.com>
Sponsored by:	The FreeBSD Foundation
MFC after:	3 days
2476178e melifaro March 21, 2021, 6:15 p.m.
Reported by:	Marco Zec <zec at fer.hr>
MFC after:	immediately
57b9a062 delphij March 21, 2021, 5:22 p.m.
MFC after:	1 month
6234a0bf delphij March 21, 2021, 5:12 p.m.
multiple times.

MFC after:	1 month
d22883d7 jah March 21, 2021, 2:23 a.m.
e4b8deb22227 removed the last in-tree uses of PCPU_INC().  Its
potential benefit is also practically nonexistent.  Non-x86
platforms already implement it as PCPU_ADD(..., 1), and according
to [0] there are no recent x86 processors for which the 'inc'
instruction provides a performance benefit over the equivalent
memory-operand form of the 'add' instruction.  The only remaining
benefit of 'inc' is smaller instruction size, which in this case
is inconsequential given the limited number of per-CPU data consumers.

[0]: https://www.agner.org/optimize/instruction_tables.pdf

Reviewed by:	kib
Differential Revision:	https://reviews.freebsd.org/D29308
f9693bef mm March 21, 2021, 1:17 a.m.
Notable upstream pull request merges:
  #11652 Split dmu_zfetch() speculation and execution parts
  #11682 Fix zfs_get_data access to files with wrong generation
  #11735 Clean up RAIDZ/DRAID ereport code
  #11737 Initialize metaslab range trees in metaslab_init
  #11739 FreeBSD: make seqc asserts conditional on replay
  #11763 Allow setting bootfs property on pools with indirect vdevs
  #11767 FreeBSD: Fix memory leaks in kstats

Obtained from:	OpenZFS
MFC after:	2 weeks
81520992 debdrup March 21, 2021, 12:08 a.m.
ipv6_ipfilter_rules was obsoleted because of ipfilter was updated, and
rc_parallel_start was reverted to undergo further refinement.

PR:		254398
Fixes:		e2ad10e84792, f61831d2e8bd
15deee52 dim March 20, 2021, 10:15 p.m.
Optional features belong in the latter file, and should be tested using:

.if ${MK_FEATURE} == no
839fdcfc jrtc27 March 20, 2021, 5:58 p.m.
Currently macOS and DragonFlyBSD get their own special case and only
handle x86. Since all the FreeBSD cases should be general enough for
macOS and DragonFlyBSD (and the x86 ones are identical to the existing
ones) we can just delete the special cases and reuse the FreeBSD ones.

Note that upstream has since removed all the architecture-specific
checks in this file, with the only code relevant to us being an
endianness check that uses the generic compiler-provided macros. Thus
this patch will not be upstreamed, and will be dropped in a future
vendor import.

Reviewed by:	dim
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D29352
ee7ffaa2 vmaffione March 20, 2021, 5:15 p.m.
- Call vm_object_reference() before vm_map_lookup_done().
- Use vm_mmap_to_errno() to convert vm_map_* return values to errno.
- Fix memory leak of e->obj.

Reported by:	markj
Reviewed by:	markj
MFC after:	1 week