Address @manu 's comments.

After the last two diff updates the patch is no longer blocked on the pctrie batching patches and is ready for review. I'd appreciate any input on this patch (and other in the series).

Minor style fixes.

Address @manu 's comments - include sdhci_fdt_rockchip.c in files.arm64.

Add the sdhci_fdt_xilinx.c to the aarch64 build files.

Minor style(9) fixes.

Properly handle howto bitmask.

Remove redundant initialization steps.

Address @manu 's comments:

• Correct authorship info
• Split out xilinx-specific code into a separate file
• Move several generic reoutines into sdhci_fdt.c

Adjust calls to xsave_* routines after changes in D48466.

In D48530#1107313, @manu wrote:

You should add the file to one of the std.XXX file in sys/riscv/conf

Address @manu 's comments.

Address @jrtc27 's comments.

Address @jrtc27 's comments.

Address @br 's and @jrtc27 's comments:

• remove redundant property checks
• style fixes

Address @manu 's comments:

• Correct copyright lines
• Add missing sdhci_fdt.c to build

In D47044#1097367, @dougm wrote:

This is a challenging patch to review, and every time I start to review it, I want to rewrite it to make it clearer. I'll hold off one more time. But I really don't think that enums or switches with fallthroughs really help much.

I agree that it's a bit verbose and I really appreciate your feedback on this patch.
I'd really like to have some flavor of batch insertion in the tree, but I'm not hell-bent on landing the current iteration of the patch.
I'll suspend work on this until your memq removal patch lands as that'll make performance evaluation and development easier.
In the meantime, I'd appreciate if you could share any tips on how you'd like this patch to look like.

Simplify patch by switching to loop-based vm_page_iter_insert radix insertion.

Address @kib 's comments.

Address @dougm 's comments.

Fix compile errors when building without NUMA.

Address @alc 's comments.

Dropping this revision since it was made obsolete by D47394.

Update driver to use XSAVE interfaces added in D47394.

Address @kib 's comments.

Refactor patch to avoid precalculating the number of nodes or passing allocfn to subr_pctrie.c:

• the old pctrie_batch_insert logic was moved into pctrie.h
• lookup logic was split out into a separate lookup function
• pctrie.h will now use said lookup function to allocate nodes and pass them to pctrie_batch_insert using a "lookup result" structure

Address @kib 's comments:

• Move XFEATURE component metadata into xsave_area_desc

Address @kib 's comments:

• Move checks to assertions
• Check for use_xsave

Address @kib 's comments:

• split specialreg.h definitions into separate commit
• move xstate routines to amd64/fpu.c

Address @dougm 's comments:

In D47044#1079505, @dougm wrote:

If you're inserting batch [a,b,...,y.z], and if you began by inserting a and z with normal iter-insert, then your BATCH_SPLIT case would never happen and some of the complexity of batch_insert could be reduced. True or false?

Address @dougm 's comments:

• Removed separate lookup function and enum type
• Explicit range lookup before insertion
• Moved pctrie_iter_insert to subr_pctrie.c so it can be used for single-element insertions

A quick remark regarding code placement - I couldn't decide where this code should reside so I ultimately placed it in cpu_machdep.c, but I'm not too happy about it.
I'd certainly like to hear your thoughts on where this should reside.

In D47046#1078597, @alc wrote:

I'm looking at patches from both you and @dougm that define this function. However, each of you adds it in a different location within the file. :-)

There doesn't seem to be any rhyme or reason to the order of the function definitions. Could we please decide on one, and add this function accordingly?

Address @dougm 's comments.

I'd appreciate if you could break this patch into a couple of smaller ones, it'll make D47271 easier to review as well.

In D46985#1071417, @kib wrote:

Since XSAVES always use the compact format, and since we already handle the save area format differently for XSAVE. I suggest to not add the pt_save_area structure definition as is. If we ever want to add yet another system feature from XSAVES, using such structures cause exponential explosion of the needed definitions. It is better to define the pt_ext_area, and then calculate the position of it in the save area based on the feature bitmap.

Address @kib 's comments.

LGTM, it would be good to briefly note this change in the 'Physical Memory Stats' section of the top(1) manpage as well.