Fix comments and manpage for 0-based start values. Generalize to BIT_FLS_AT and to FLC versions of everything to find clear bits.

Another note of interest:
I find two uses of BIT_FFS_AT in the code:

Tweak the mask-last-bits test.

A point of confusion: if 'start' is a one-based index, as the comment claims, then how is
#define BIT_FFS(_s, p) BIT_FFS_AT((_s), (p), 0)
correct? Wouldn't it be:
#define BIT_FFS(_s, p) BIT_FFS_AT((_s), (p), 1)
Really, I suspect the comment is wrong.

Move the functions from vm_page.h to vm_extern.h. Rename them, and add a couple of comments.

In D33685#761339, @markj wrote:

IMO vm_phys.h makes more sense than vm_page.h for these routines. The vm_page_ prefix is usually for functions that operate on a vm_page_t. Is there some reason these can't live in vm_param.h as kib suggested?

Drop a redundant zero-check.

common.boundary -> boundary, on some architectures.

Find more places to use align_ok and bound_ok.

Drop set_pool. Move alignment checks to vm_page.h. Use them in sys/dev/iommu.

In D33685#761212, @kib wrote:

You may also convert sys/dev/iommu/iommu.h iommu_test_boundary()

Undo last change.

Correct a bound error. Update for changes in surrounding code.

Remove the alignment change. I think boundary is the only problem.

Catch another boundary == 0 problem.

Assume that if I'm wrong about boundary, I'm similarly wrong about alignment.

Update after commit 0d5fac287294490ac488d74e598e019334610bdb

Fix indentation. Move some code out of the scope of locks, as suggested.

Correct page accounting problem.

Improve comments.

Make changes in bitstring.h, and in vm_reserv_break, to shrink the object code size a bit. Some allow the compiler to optimize out code when compile-time constants are multiples of 64. Some allow the same code to find 1-bits as 0-bits, so that two nearly-identical copies of the code are not generated.

This change does slightly reduce the code size:
dougm@108-254-203-204:GENERIC $ size orig.vm_page.o

 text    data     bss     dec       hex   filename
50782   25808   13424   90014   0x15f9e   orig.vm_page.o

dougm@108-254-203-204:GENERIC $ size vm_page.o

 text    data     bss     dec       hex   filename
50670   25808   13424   89902   0x15f2e   vm_page.o

Use roundup2 instead of rounddown2, since it is used elsewhere here, and because it is easier to spell.

Rewrite the alignment/boundary rounding a bit more carefully.

Slightly reduce the object code size by dropping over-optimization in vm_reserv_find_contig.

Use '__diagused' to avoid creating a function just to call it from KASSERT.

The code this modifies has been substantially changed now, and the benefits of this change no longer apply.

Update after commit 6f1c8908272f3c0a6631e001bd2eb50a5b69261d.

Change stray tab to space.
Avoid ulmin, ulmax for vm_paddr_t boundary.

Drop debug code. Push ppn_align and ppn_bound into [1,VM_LEVEL_0_NPAGES] to avoid overflow problems.

Compute the shifted alignment and boundary values once, not with every find function call, and make sure they aren't zero-valued.

Correct identifier name. Verify compilation.

Apply reviewer suggestion. Remove some upper bound checks on alignment and boundary. Add some zero and power-of-two kasserts on alignment and boundary.

Accept 3 reviewer suggestions.

Rename a couple of parameters to vm_reserv_find_contig. Add assertions and comments to ensure/explain that arithmetic with bound and alignment cannot compute values beyond the number of pages in a reservation.

Shrink whitespace. Fix pages vs bytes error. Stop using FUNCTION.

Make all the arithmetic in the helper function use ints, and let the caller handle conversion to int. Let the caller manage bounds calculation. Return the found page and let the caller check assertions to verify alignment.

Use roundup2() to hide the bit-twiddling in alignment and boundary adjustment. Work with the page number directly instead of going back to the address for calculation.

Don't allow boundary to exceed reservation size, so that boundary arithmetic cannot be a problem.

Don't bother checking a reservation if every address within it violates alignment.

Which revision did you create the diff from?

On further review, I think I changed the wrong value to a different wrong value the first time.

Seems harmless.

Looks okay to me.

Update to match underlying file changes.