Page MenuHomeFreeBSD

xen/arm64: enable arm64 Xen configuration
Changes PlannedPublic

Authored by on Jun 30 2021, 1:15 AM.



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 <>
Original implementation: Julien Grall <>, 2014-01-13 17:40:58

Diff Detail

rS FreeBSD src repository - subversion
Lint OK
No Unit Test Coverage
Build Status
Buildable 40179
Build 37068: arc lint + arc unit

Event Timeline

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. added parent revisions: D30297: arm64/nexus: use actual PA range for I/O memory limit, D30554: ofwbus: remove handling of resources from ofwbus, D30599: xen/intr: rework xen_intr_resume() to use port mappings as implicit listing, D30598: xen/intr: merge parts of resume functionality into new function, D30006: xen/intr: adjust xen_intr_handle_upcall() to match interrupt filter, D29959: xen/devices: purge uses of intr_machdep.h, D29913: xen/intr: move x86-only variable out of common, D29875: xen/arm64: add handling of Xen device-tree, D29873: etc/ttys: add the xen console, D29811: xen/xen-os: move inclusion of machine/xen-os.h later, D29599: xen/control: print warning on call of xctrl_suspend(), D29500: xen/intr: use struct xenisrc * as xen_intr_handle_t, D29406: xen/control: introduce xen_pv_shutdown_handler(), D29405: xen/netfront: introduce xen_pv_nics_disabled(), D29404: xen: introduce PCPU_ID_GET(), D29403: xen: introduce xen_pv_disks_disabled(), D29402: xen: introduce xen_support_evtchn_bind(), D29351: xen: create VM_MEMATTR_XEN for Xen memory mappings, D29306: xen/control: disable 15226522304868a8312a84f8ff549fdc6bbf54db on !x86, D29304: xen/xenpv: remove low memory limit for non-x86, D29042: xen: move x86/xen/xenpv.c to dev/xen/bus/xenpv.c, D29041: xen/timer: make xen timer optional, D28982: xen: move common variables and code off of sys/x86/xen/hvm.c, D29498: xen/arm64: introduce sys/arm64/include/xen/xen-os.h, D30236: xen/intr: move sys/x86/xen/xen_intr.c to sys/xen/xen_intr.c.Jun 30 2021, 1:28 AM

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.

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.

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.

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.

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.