A really *gross* solution, but something which works for now. Hopefully
the next person is better with the proper machine-independent in-kernel
APIs for FreeBSD.
You might look at pmap_qenter() for this. Rather than physical addresses, it expects an array of vm_page_t. These can be obtained from resume_frames using the PHYS_TO_VM_PAGE macro.
There is also a pmap_qenter(9) man page.
__i386__ is preferred to __x86__ within FreeBSD.
I don't see a need to add __arm__ to this list until someone tries to support it fully.
That man page does provide pretty good information. Right now though interrupt issues are a higher priority (appears the kernel is presently hanging due to interrupts, this version of the grant table doesn't appear to cause panic).
Latter: While my goal is getting aarch64 operational, it seems worthwhile to try an aarch32 build at some point. In particular since getting aarch64 operational is likely to fix 95% of the aarch32 issues, it seems likely to be worth a little bit of effort. The one challenge is I'm unsure where the shared bits would go. Right now it really looks like nearly all of the issues for aarch64 are also issues for armel/armhf/aarch32 and riscv.
This is not correct, you seem to assume start_idx will always be 0, but that's not the case, see gnttab_expand for example.
You would need to use something like:
pmap_kenter((vm_offset_t)shared + start_idx * PAGE_SIZE, (end_idx - start_idx + 1) << PAGE_SHIFT, resume_frames + start_idx * PAGE_SIZE, VM_MEMATTR_DEFAULT);
Or alternatively maybe:
#ifdef __aarch64__ #define pmap_kenter(l, p) pmap_kenter(l, PAGE_SIZE, p, VM_MEMATTR_DEFAULT); #endif
Hopefully things are sufficiently addressed now. This has been tested on an actual build and seems to be functioning.
I would prefer the Real Fix of using pmap_qenter() or other architecture-independent functions, but right now my goal is simply trying to reach a shell.