xen/console: add support for HVM and ARM console

[ehem_freebsd_m5p.com]

Summary

This should be improving the console on ARM devices. I'm unsure of the
magnitude of improvement, but it does get a very early console
functioning on ARM devices.

Submitted by: Elliott Mitchell <[e-mail]>
Original implementation: Julien Grall <[e-mail]>, 2015-09-19 10:15:40

[royger]

I think the comment about pmap not being initialized for HVM needs some clarification.

sys/dev/xen/console/xen_console.c

279

I'm lost here, both HVM and PVH use exactly the same pmap init code, so I'm not sure why pmap_mapdev_attr would work in one case and not the other?

Is maybe something else that's missing, and not pmap initialization?

[ehem_freebsd_m5p.com]

This one needs @julien_xen.org to comment. So far none of my successful builds lacked this, but a build without it might work.

As such I believe the dependency markings reflect the current situation. I don't know D30950 actually depends on D29597, even though I suspect D30950 depends on D29597.

[julien_xen.org]

In D29597#696444, @ehem_freebsd_m5p.com wrote:

This one needs @julien_xen.org to comment. So far none of my successful builds lacked this, but a build without it might work.

As such I believe the dependency markings reflect the current situation. I don't know D30950 actually depends on D29597, even though I suspect D30950 depends on D29597.

I can't remember why I wrote this patch. If Arm guests are treated as HVM guests, then the behavior doesn't look to change for the initialization.

Can you drop the patch and try to boot?

sys/dev/xen/console/xen_console.c

300

AFAICT, after with the change in xencons_early_init_ring() , cons->evtchn and cons->intf will not be set for PV but HVM domain.

[julien_xen.org]

sys/dev/xen/console/xen_console.c

281

I am not sure to understand how the code match the comment. The function will skip the initialisation for non-HVM domain... IOW after this patch, the function will still initialise the ring for HVM domain.

[ehem_freebsd_m5p.com]

In D29597#696570, @julien_xen.org wrote:

Can you drop the patch and try to boot?

I don't know whether my build/test setup is worse than others', but I really dislike that test approach as my builds take a while. This though is the test and quite effective. Appears this is no longer necessary, so dropping this. (latest build looked okay in regards to this, even though -CURRENT has some troubles right now)