xen/xenpv: introduce xen_arch_alloc_addr()/xen_arch_release_addr()

[ehem_freebsd_m5p.com]

Summary

Non-x86 architectures place different constraints on the address of the
Xen address allocations. As such introduce xen_arch_alloc_addr() to
allow architecture-specific code to allocate the address space.

[ehem_freebsd_m5p.com]

This would replace D29304.

The idea is a function like this would allow aarch64 to use the device-tree to specify where to place the grant-table (and other Xen MMIO). Such could also place appropriate limits on addresses used.

[ehem_freebsd_m5p.com]

I should state, I'm unsure whether to declare these in sys/xen/xen-os.h versus sys/x86/include/xen/xen-os.h. For x86 these could be static inline functions, for ARM I suspect they will end up as actual functions (unless one variable ends up global). One trick is they do need a number of headers to be #include'd to work. I got to a fairly minimal set of headers, but it may be possible to cut further.

[ehem_freebsd_m5p.com]

I should also provide an update on this. I tried and successfully used this to place the grant table in Xen/ARM's recommended address range. The implementation was to add a struct rman to xen-dt.c which was then initialized from the resource. rman_reserve_resource()/rman_release_resource() were then used for the actual allocation.

[ehem_freebsd_m5p.com]

For the purposes of ARM, the API might be better to have a xenpv_set_addr_mgr(struct rman *) function. This allows for the allocated range to come from either device-tree or ACPI table. There are two outstanding issues.

x86 needs to be able to setup a resource manager to provide to the XenPV code.

How does the Xen project view the range provided? Meant for grant-tables only? Meant for any foreign mapping? Will a larger range be suggested for larger VMs?

[ehem_freebsd_m5p.com]

There are questions of approach for this. While this has demonstrated viability, there are sufficient concerns for this not to be ready yet. The alternative is D29304 which has a distinct issue.

[ehem_freebsd_m5p.com]

This approach did yield working builds, but with the other approach's major issues worked out that looks better. Well past time to abandon this. This one isn't going to return from the scrapheap.