I guess rounding buflen1 up to a multiple of page size, when maxsegsz is not a multiple of page size, is a problem. So restore check to reduce buflen1 to maxsegsz.

iommu_map->iommu_gas_map->iommu_gas_find_space requires that the size parameter be a multiple of page size, so restore the round-up to respect that.

Change the type of a shifted bit to vm_paddr_t.

Address reviewer comments. Shift 1UL (instead of 1) and 2UL (instead of 2) in the code being modified here. This isn't making changes to code elsewhere to which the same concerns may apply. Add a zero-check before backing up from one address to its precesessor.

Alc comments, and objects, verbally. I recap:

Abandoning this. Too much overlap with another outstanding patch may create confusion, and I need to rearrange some of the stuff here anyway.

Restore the commented out code for capturing small initial blocks in the allocation. Change the code that frees small leftover blocks at the end so that it does not assume that the allocation must have started at the start of a big aligned block.

Perhaps there is something unhealthy about backing up over small blocks at the beginning. Blank that out and see if tests still fail.

Take those parts of D34729 that seem unobjectionable and leave them here, discarding the rest, so that testing and review of this change can proceed independently.

Rename some functions from 'alloc' to 'find', since they no longer alloc. Add a check to stop some searches doomed by alignment.

Fix comment typo.

Add/edit comments only.

I'll commit this tomorrow, if no one has more to say about it.

Go back to allocating from queues, not segments.

In D33947#786095, @markj wrote:

vm_phys_alloc_seg_contig() will ignore runs of pages that aren't contained in the range [seg->start, seg->end], so doesn't this change potentially cause us to skip over eligible runs?

Throw out almost everything.

Whitespace cleanups.

I have no objections, but it was kib, I think, who asked for the invariants in the first place, so get his ok too.

Eliminate typedef. Eliminate gotos.

Update stale comment.

Change the process of stringing together free blocks to satisfy a request to allow smaller blocks at the beginning and end of the sequence. When a free block is not part of a large enough range to satisfy the request, move the largest free blocks in the sequence in their free list so that they aren't encountered more than once in the search. When a request for a number of pages less then the maximum block size cannot be satisfied with a single free block, try to piece a sequence of smaller free blocks together before giving up.

Allow a less-than-max-sized free block to complete the allocation.

Accept all proffered advice.

Update, rearrange comments.

Reverse the order in which diminishing-sized free blocks are enlisted.

Correct error in KASSERT print output.

Avoid passing pointer differences to ffs, fls.

Remove some offensive parts.

Undo change involving fictitious seg.

Fix initial mask on area_at. Fix off-by-one in end test on area_at. Add some test cases.

Define a bit_ntest function, document it, and use it in place of bit_ffs in a couple of places.

Make tinderbox completed with just these errors:
powerpc.powerpc64: make[6]: "/freebsd/dougm/base/src/stand/kboot/Makefile" line 27: Cannot open /fr
eebsd/dougm/base/src/stand/kboot/arch/powerpc/Makefile.inc

Abandoning. I'll limit myself to bitstring.h. There are too many weird decisions baked into bitset.h for me to use it.

Oh, I see. Your 'greater than a start bit' makes your decision to call this 1-based correct. Confusing to me, but correct. Sorry to bother you.

Clean up an inadvertent whitespace change in the test code.

Nevermind. The boundary rewrite would break the boundary == 0 case.

Add semicolons.

Fix a bunch of mistakes I should not have made, and use "%#" for the first time.

Use powerof2.

In D33725#762451, @kib wrote:

Why not use powerof2() macro from sys/param.h?

Fix an error in the test code, checking for ffs legal return values.

Add ffs and fls tests to the bitset test set.

In D33701#762111, @se wrote:

This is especially problematic since the CPU_SET macros are based on BIT_SET macros, and they are critical for the correctness and security of kernel functions.