xen/console: add hook for xen_early_init()

[ehem_freebsd_m5p.com]

Summary

xencons_cnprobe() is an ideal point to probe for the presence of the Xen
hypervisor. This is the first place which MUST know whether Xen is
present (unless the console is disabled).

For x86 there are other earlier spots where Xen's presence is currently
probed, but for other architectures this is ideal.

[ehem_freebsd_m5p.com]

Should be obvious, for aarch64 xen_early_probe() simply ends up being a normal function declaration in sys/arm64/include/xen/xen-os.h and the function in D29875 does the job.

[ehem_freebsd_m5p.com]

I should note there is a distinct ordering issue shared between D29498, D29875 and D30816.

The last step is to add a declaration of xen_dt_probe() to aarch64's xen-os.h. This would also define xen_early_probe() to call xen_dt_probe(). My feeling is whichever one goes in last should include that declaration. Right now though I'm unsure which will end up merged in last, therefore that hunk is currently a separate commit in my repository.

The reason the macro is xen_early_probe() while the function is xen_dt_probe() is this allows flexibility. In particular it might become possible to probe for Xen's presence via ACPI/EFI. In that scenario xen_early_probe() on arm64 would be changed to call both xen_dt_probe() and xen_efi_probe().

[ehem_freebsd_m5p.com]

Taking a look at this, D29875 shouldn't actually be marked as a child of D30816. D29875 should build fine without D30816, just a build with D29875, but not D30816 will be missing the console. In fact I wonder whether D30950 should be a child of D30816, since a VM without a console could function acceptably (debugging would be painful, but it could be quite useful).

There is more of a peer dependency since the xen_early_probe() (or perhaps xen_domain_early()) needs to match.

sys/dev/xen/console/xen_console.c

622

I'm suddenly wondering about this name. This simply needs to be a xen_domain() call which may need to include a Xen probe depending on architecture. On ARM64 the only reason Xen needs to be probed here is this is the first point where Xen's presence or absence matters.

As such perhaps this should be xen_domain_early()?

[mhorne]

sys/dev/xen/console/xen_console.c

622

It seems like you are hiding this probe in a weird place. Can it be called from initarm() directly, just ahead of cninit()? That way, it does not depend at all which xen device gets initialized first, and xen_domain() should work as expected here (yes?).

[ehem_freebsd_m5p.com]

sys/dev/xen/console/xen_console.c

622

Calling it from initarm() would work fine, @julien_xen.org's original implementation used that strategy (which has been tried and confirmed to work). This though lead to D29874 which includes a reasonable criticism of the approach.

The real issue is console devices are initialized before SI_SUB_HYPERVISOR. As such this or another early probe is needed to ensure the Xen console is available on ARM. I haven't tried my FreeBSD/ARM64 on Xen with console disabled, but in theory it should work fine (since D29875 includes a backup probe during SI_SUB_HYPERVISOR).

[royger]

IMO would be better to do this probing inside of an Arm specific early init routine, but if the current approach works and it's the prefered way for Arm people that's fine with me.