xen/arm64: enable arm64 Xen configuration

[ehem_freebsd_m5p.com]

Summary

The step of enabling the setup in general is better a separate commit.

This was broken off of "xen/arm64: add xen platform".

Submitted by: Elliott Mitchell <[e-mail]>
Original implementation: Julien Grall <[e-mail]>, 2014-01-13 17:40:58

[ehem_freebsd_m5p.com]

This was mostly created to mark the end goal and indicate diffs which are required before this is ready. Right now not all diffs are even present.

[ehem_freebsd_m5p.com]

At this point there is one required delta owned by @mhorne which may not pass through Phabricator.

There is one hunk which should be part of either D29875 or D30816, but I'm unsure which to merge it into since I'm unsure of order. I suspect D29875 will be second, in which case it should go there, but I'm unsure that is how things will turn out.

There is one delta owned by @royger which may or may not actually be required and may not pass through Phabricator.

So two portions are presently absent, but a minimally functional implementation of FreeBSD on Xen/ARM64 is 99% available now.

[ehem_freebsd_m5p.com]

I've confirmed the commits not in Phabricator are required (one owned by @mhorne, one owned by @royger). Until those are in, D30950 is going to remain at changes planned status.

Good news is get this set in and FreeBSD/ARM64 as Xen DomU works.

[ehem_freebsd_m5p.com]

Question for whomever has the answer. When would it be appropriate to enable XENHVM for FreeBSD/ARM64?

There seem to be four points after which it makes sense. These are after particular batches get submitted/committed. The four groups are patches/commits which:

1. Fix breakage in ARM64 build (example: D29959).
2. Fix breakage during boot (there used to be some, these may have subsumed into the above or below groupings)
3. Fix breakage likely to manifest during runtime (example: D30297; this isn't guaranteed to manifest during a given uptime, but there is substantial risk of a panic sometime before planned shutdown)
4. Fix performance/features (example: D31690)

Presently patches/diffs in groups 1-3 are included as parents of D30950. I'm starting to think perhaps only the ones in group 1 should be parents of D30950. Theory being once a reliably building state has been reached, we want a major alert to newly introduced breakage immediately.

What about the release notes, when should Xen/ARM64 be added there? Should I submit my first pass at an entry to Phabricator now? Should it be added once group 3 is done? (submit to Phabricator and make everything in group 3 parents of the diff)

While D31690 may be a substantial performance issue, I'm confident the support will be quite useful without group 4.

[ehem_freebsd_m5p.com]

Might merely be trivia, but a remaining example of group 2 would be D29602. The boot process doesn't get very far without it, but the ARM64 build certainly completes without it.

[ehem_freebsd_m5p.com]

Experimental builds have demonstrated high reliability. There may still be issues lurking and some things are expected to be revised, but this project is less than 30 reviews away from completion.

[ehem_freebsd_m5p.com]

Returning to reviewable state since the last required commit is in.