fa1ac969 gbe Aug. 7, 2022, 2:08 p.m. 
- s/paramater/parameter/

MFC after:	3 days
cgit
b2b1bb04 gbe Aug. 7, 2022, 2:07 p.m. 
- s/paramaters/parameters/

MFC after:	3 days
cgit
0702f4f0 gbe Aug. 7, 2022, 2:05 p.m. 
- s/paramater/parameter/

MFC after:	3 days
cgit
044169ef gbe Aug. 7, 2022, 2:01 p.m. 
- s/paramaters/parameters/

MFC after:	3 days
cgit
ffcec862 osa Aug. 7, 2022, 1:59 p.m. 
Reported by:	Adrian Steinmann <ast@NetBSD.org>
Fixes:		a3d933cc4f2300b476151c2dd3fa455882f3aa97
MFC after:	3 days
cgit
cc538081 gbe Aug. 7, 2022, 1:58 p.m. 
- s/paramater/parameter/

MFC after:	3 days
cgit
09451711 gbe Aug. 7, 2022, 12:53 p.m. 
- cannot parse date, using it verbatim: Dec 15, 1997"
- sections out of conventional order: Sh SEE ALSO
- possible typo in section name: Sh EXAMPLE instead of EXAMPLES
- AUTHORS section without An macro

MFC after:	3 days
cgit
cd330397 gbe Aug. 7, 2022, 12:20 p.m. 
- s/Unreachablity/Unreachability/

MFC after:	3 days
cgit
4c399b04 gbe Aug. 7, 2022, 12:04 p.m. 
- s/examing/examining/

MFC after:	3 days
cgit
c9254546 pho Aug. 7, 2022, 8:37 a.m.
ac79b5f3 pho Aug. 7, 2022, 8:35 a.m.
a3d933cc osa Aug. 6, 2022, 7:02 p.m. 
Add NetBSD 9.3, it's been released two days ago.

MFC after:	3 days
cgit
69893a0e osa Aug. 6, 2022, 6:58 p.m. 
Add two releases to the tree.

MFC after:	3 days
cgit
7f2ec173 dougm Aug. 6, 2022, 6:26 p.m. 
iommu_gas_augment_entry updates a map entry element. Invoked as
RB_AUGMENT in RB tree code, it is applied from the point where the
tree is modified, all the way up to the root, and is also applied when
rotation moves a node down in the tree.

There are several opportunities to invoke it less. The automatic
augmentation with every rotation is a mistake.  Delaying these
augmentations until RB_INSERT_COLOR or RB_REMOVE_COLOR are finishing
allows the augmentation code to be duplicated less, to work when there
is less register pressure, and to be skipped when conditions allow it:

    In the double-rotate case of RB_INSERT_COLOR, augmentation after
    the first rotation is not necessary when the element being moved
    down the tree becomes a leaf. It was in the tree, and was a leaf,
    before the RB_INSERT operation began, and so recomputing
    augmentation for it would do nothing.

    In the final (possibly only) rotation of RB_REMOVE_COLOR, both the
    elements - the one moving up and the one moving down - end up in
    the path from the deletion point to the tree root, so there's no
    need to augment either of them immediately.

    In RB_REMOVE, when the right child of the removed node replaces it
    in tree, it began with a null left child. Replacement creates a
    non-NULL left child, and then rotation may put a NULL node back in
    that place. If that happens, start the augmenting-up-to-root with
    the parent of that node, since augmentation would do nothing.

Adjust to avoid these needless augmentations.

Reviewed by:	alc
MFC after:	3 weeks
Differential Revision:	https://reviews.freebsd.org/D35502
cgit
7f46decc alc Aug. 6, 2022, 6:05 p.m. 
Restructure dmar_qi_task() so as to reduce the number of invalidation
completion interrupts.  Specifically, because processing completed
invalidations in dmar_qi_task() can take quite some time, don't reenable
completion interrupts until processing has completed a first time. Then,
check a second time after reenabling completion interrupts, so that
any invalidations that complete just before interrupts are reenabled
do not linger until a future invalidation might raise an interrupt.
(Recent changes have made checking for completed invalidations cheap; no
locking is required.)

Reviewed by:	kib
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D36054
cgit