xen/arm64: introduce sys/arm64/include/xen/xen-os.h

[ehem_freebsd_m5p.com]

Summary

Based on a 2014-01-13 17:40:58 commit by Julien Grall <[e-mail]>
titled "xen/arm64: add xen platform". This is one of many fragments
resulting from that commit.

These are the values appropriate for ARM64 on Xen. Since the ARM64
implementation is more recent, there are fewer changeable settings and
most are constants (unlike x86).

xen_pmap()/xen_unmap() were replaced by VM_MEMATTR_XEN. ARM
specifically needs these mappings cacheable, as such prefer
VM_MEMATTR_WRITE_BACK over VM_MEMATTR_DEFAULT.

Submitted by: Elliott Mitchell <[e-mail]>
Original implementation: Julien Grall <[e-mail]>, 2021-06-28 15:31:57

[ehem_freebsd_m5p.com]

My thinking is, if this is brought in now then various commits could include both the x86 and ARM settings. Thus illustrating why those needed to be added. Notably, D29351, D29402, D29403, D29404, D29405, and D29406 all use distinct implementations for ARM.

The downside is this leaves a mysterious header hanging out in ARM64 land apparently doing nothing until the rest of Xen/ARM is operational.

[mhorne]

In D29498#661137, @ehem_freebsd_m5p.com wrote:

My thinking is, if this is brought in now then various commits could include both the x86 and ARM settings. Thus illustrating why those needed to be added. Notably, D29351, D29402, D29403, D29404, D29405, and D29406 all use distinct implementations for ARM.

The downside is this leaves a mysterious header hanging out in ARM64 land apparently doing nothing until the rest of Xen/ARM is operational.

Although I understand your reasoning, I do not think this is the right way to handle this.

The reviews you linked are useful in their own right: they do the preliminary cleanups required to accommodate support for a new architecture. Adding the arm64 versions of those definitions is outside the scope of this, since that support doesn't exist yet in FreeBSD.

Introducing this header in such a piecemeal way will complicate the history. I would rather see it committed in its entirety alongside other relevant pieces of the arm64 xen support.

[ehem_freebsd_m5p.com]

Now realizing I misunderstood Roger Pau Monné's comment, I basically agree with Mitchell Horne on his view. Even had I understood correctly on the first try, this approach was worthy of considering anyway.

[ehem_freebsd_m5p.com]

I keep coming back and wondering if this really is the way things should be done. There are a bunch of commits which potentially merely add a line or two to this file and don't really own it. This would also serve as the marker for where the real implementation of Xen/ARM support starts in history.

[ehem_freebsd_m5p.com]

While the new version will include rather more in the file during introduction, I'm still finding this file seems to function best being introduced by itself. The new revision though will include a bunch of the constants which x86 includes in its version of the file.

[ehem_freebsd_m5p.com]

Mostly going to be redoing most of this, but this is likely to be a single version.

[ehem_freebsd_m5p.com]

Updating to current version. This is nearly everything which ends up here.

[ehem_freebsd_m5p.com]

Guess this really does need review at this stage.

[ehem_freebsd_m5p.com]

Doing some later testing and notice for D29498, FreeBSD's style is parentheses around return values. I'll be updating that, but this other item showed up.

sys/arm64/include/xen/xen-os.h

55–56

@julien_xen.org I'm in the middle of testing related to this. The code and comment disagree here. If it is always possible to rebind event channels on ARM, this should be returning true instead of false.

Simply a goof during development and your project never got to the point of testing this?

[ehem_freebsd_m5p.com]

Adjusting return of xen_support_evtchn_rebind(). This is expected to be renamed later (possibly during commit), but for now simply update Phabricator so wrong thing doesn't get committed. Correct value is "true" since this is available on aarch64.

[ehem_freebsd_m5p.com]

Update to reflect current situation. Notably the macro name has been proposed as XEN_CPUID_TO_VCPUID. That is awaiting final review, but I presently believe that is going to be the final name.