Fix the diff

Don't use config_intrhook_establish(), the mutex isn't initialized yet.

@kevans committed this in r352863 2 weeks ago.

I really like that you took the time to annotate the existing code. It's tough to read and understand it the first several times through.

Looks good for what we can do for now. I really should clean up the whole DPAA interface bits, so we don't need to do that loop. But since it's only executed on bootup, it's not a very high priority task.

Address @emaste's comments

Address andrew's feedback. Thanks!

This will simplify D21682 a bit, as well. PowerPC has sub-word atomics since PowerISA 2.06, so we'll need dual personality there.

Can you add a key/sentinel into the dump structure to say what pmap it's using? libkvm will need it for properly decoding addresses, and that differential will also need to be updated to use the key and select a backend.

This is very specific to AIM64 HPT. Can you rename it to kvm_..._hpt.c, or something, and add another key to the header to probe against for the particular pmap implementation? I'll want to add Book-E support, as well as AIM Radix when we do finally get radix stabilized.

r352313

This should be able to go in before flag day, there's nothing preventing it from working (we don't need linker support just for this, it's all in code).

Only a trivial review so far.

I like it, except for the typo :)

@i_maskray.me, you're right. It should just be

Can you instead add something like the following to crt1.c?

Address luporl's comments.

On Book-E it's already allocated out of KVA, as part of the bootstrap carving. Looks like on AIM I could just adjust virtual_avail as you mention in your comment in D21491, there would be up to 32MB (less 2 pages) slop, (15MB less 1 page on either side) which is probably fine on NUMA machines. But we do only have 32GB KVA available currently, and if the vm_page_array is ~3% of total memory, on a 256GB machine that's ~8GB, which is pretty big. I think I'd rather hold off on it until we either increase KVA or get actual working dump support.

@mjg glib does use fdwalk() if available, and emulates it where needed. This work I started specifically because I saw this same code flow in multiple ports.

Address feedback. I think this is better overall, simplifies things.

This change appears to give me a 15-20% improvement with building llvm on my Talos (144 thread POWER9). No change at all with buildworld.

You're right, I don't know what I was thinking. The page_range change is the only thing needed from this diff.

Fix 32-bit build.

It shouldn't be built for powerpc32, only powerpc64. However, it doesn't hurt anything, and is a good belt-and-suspenders change.

Address @kib's feedback. The man page will probably need more iterating, but I
think the code is correct. It may not be optimal, though.

Don't call getpid(), we can pass 0 now.

Incorporate mjg's changes.

Add a new sysctl, kern.proc.fdmap.<proc>, to provide the bitmap. Walk the bitmap instead of the file descriptor list.

In D21206#461101, @mjg wrote:

It's not hard to add such a sysctl. If you want I can hack it up for you. I think it should just export the fd bitmap, then iteration over it is trivial.

Address @kib's feedback. Man page will probably require several iterations
to get right. It's still a little muddy.

Looks fine overall, just the one question. I just want to be sure this is thoroughly tested before it goes in, on the corner cases.

Looks good now.