f1442847 bz Dec. 29, 2021, 5:01 p.m.
The first time we start bhyve with a passthru device everything is fine
as on boot we do enable BARs.  If a driver (unload) inside bhyve disables
the BAR(s) as some Linux drivers do, we need to make sure we re-enable
them on next bhyve start.

If we are trying to mmap a disabled BAR for MSI-X (PCIOCBARMMAP)
the kernel will give us an EBUSY.
While we were re-enabling the BAR(s) in the current code loop
cfginit() was writing the changes out too late to the real hardware.

Move the call to init_msix_table() after the register on the real
hardware was updated.  That way the kernel will be happy and the
mmap will succeed and bhyve will start.
Also simplify the code given the last argument to init_msix_table()
is unused we do not need to do checks for each bar. [1]

MFC after:	3 days
PR:		260148
Pointed out by:	markj [1]
Sponsored by:	The FreeBSD Foundation
Reviewed by:	markj
Differential Revision: https://reviews.freebsd.org/D33628
b4a58b3d kbowling Dec. 29, 2021, 4:37 p.m.
Match igb(4) as in f7926a6d0c10. From Vincenzo, this check is redundant
to setup providing us an IGC_RXD_STAT_VP bit and would make for an
unexpected condition if IFCAP_VLAN_HWTAGGING were not set but the tag
was stripped, which would be passed up the stack breaking isolation.

PR:		260068
Approved by:	vmaffione
MFC after:	1 month
626d6992 trasz Dec. 26, 2021, 5:22 p.m.
This will always sleep at least once, so it's a slow path by definition.

Reviewed By:	kib
Sponsored By:	EPSRC
Differential Revision:	https://reviews.freebsd.org/D33387
8cfd7a6a pkubaj Dec. 29, 2021, 1:40 p.m.
Summary: It's currently just as stable as powerpc64, with more ports working.

Reviewers: alfredo, bdragon, luporl, jhibbits, #manpages

Subscribers: imp

Differential Revision: https://reviews.freebsd.org/D33610
6e1be96f andrew Dec. 29, 2021, 12:20 p.m.
Sponsored by:	The FreeBSD Foundation
99948907 ram Dec. 29, 2021, 10:45 a.m.
MFC after: 3 days
f5e24f24 ram Dec. 29, 2021, 9:04 a.m.
Reviewed by: mav
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D33668
60e749da royger Dec. 29, 2021, 8:23 a.m.
Functions manipulating mbuf tags are using an int type for passing the
'type' parameter, but the internal tag storage is using a 16bit
integer to store it. This leads to the following code:

t = m_tag_alloc(...,0xffffffff,...,...);
m_tag_prepend(m, t);
r = m_tag_locate(m ,...,0xffffffff, NULL);

Returning r == NULL because m_tag_locate doesn't truncate the type
parameter when doing the match. This is unexpected because the type of
the 'type' parameter is int, and the caller doesn't need to know about
the internal truncations.

Fix this by making the 'type' parameter of type uint16_t in order to
match the size of its internal storage and make it obvious to the
caller the actual size of the parameter.

While there also use uint uniformly replacing the existing u_int

Reviewed by: kp, donner, glebius
Differential revision: https://reviews.freebsd.org/D33680
b99651c5 np Dec. 29, 2021, 12:57 a.m.
sge->ctrlq is not always allocated during attach (eg. if firmware
initialization fails) and detach should be able to deal with this.

MFC after:	1 week
Sponsored by:	Chelsio Communications
c74ab5ce jhb Dec. 29, 2021, 12:49 a.m.
If a "raw" IPv6 address (denoted by a leading '[') is used as a target
address, then 'arg' is incremented by one to skip over the '['.
However, this meant that at the end of the function the wrong address
was passed to free().  With malloc junking enabled and given suitably
small strings, malloc() would happily overwrite the correct number of
bytes with junk, but off by one byte overwriting the byte after the

This manifested as the first byte of the 'HeaderDigest' key being
overwritten causing the key name on the wire to be sent as
'\x5eaderDigest' which the target rejected.

Reported by:	Jithesh Arakkan @ Chelsio
Found with:	ASAN (via WITH_ASAN=yes)
Sponsored by:	Chelsio Communications
1fa68dae mckusick Dec. 29, 2021, 12:39 a.m.
Requested by: pauamma_gundo.com
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D18765
24b82aa0 alc Dec. 28, 2021, 11:59 p.m.
Use pmap_pte_exists() in place of multiple KASSERT()s.

Eliminate an unnecessary NULL check.

MFC after:	1 week
3c2ee7b2 alc Dec. 28, 2021, 11:46 p.m.
Report the descriptor type and level at which the page table does not
match the caller's expectations.

MFC after:	1 week
0ecda8d5 markj Dec. 28, 2021, 10:47 p.m.
Reported and tested by:	Michael Butler <imb@protected-networks.net>
Reviewed by:	jhb, kib
Fixes:	62d09b46ad75 ("x86: Defer LAPIC calibration until after timecounters are available")
MFC after:	3 days
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D33669
deca0138 markj Dec. 28, 2021, 10:47 p.m.
We only attempt to gracefully handle absence of an APIC if "device
atpic" is defined in the kernel configuration.

Suggested by:	kib
Reviewed by:	jhb, kib
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation