x86/xen: introduce a Xen early init function

[royger]

Summary

Start by moving the hyeprcall setup to such function.

The aim is to have a function that does all the required Xen early
initialization for both HVM and PVH, instead of having it scattered across
different paths.

Sponsored by: Cloud Software Group

[markj]

sys/x86/xen/hvm.c

193

Why disable the sanitizers for this function only?

199

This doesn't look correct for !amd64 but perhaps that's ok?

I would assert that (uintptr_t)addr > KERNBASE at least.

216

It is ok to just use %u here, that is very common elsewhere in the kernel.

[royger]

sys/x86/xen/hvm.c

193

I've copied them from what amd64_loadaddr() uses, since they seem fairly similar.

199

AFAICT i386 doesn't support relocation, so the kernel is always loaded at the 2M physical boundary, and hence addr - KERNBASE is fine to use. I will add the assert.

[markj]

sys/x86/xen/hvm.c

193

I believe that's because amd64_loadaddr() is called from pmap_san_enter_early(), which is called (indirectly) from locore, before hammer_time().

If you haven't tested KASAN/KMSAN in Xen, I would just remove these annotations.

199

Ah, I was thinking of arm64. I didn't realize that this code supported i386.

[royger]

sys/x86/xen/hvm.c

193

Ack, will remove. I assumed those had to do with the function playing with pointers and using direct offsets against them. I will test with the GENERIC-KASAN kernel.

[markj]

sys/x86/xen/hvm.c

193

I will be surprised if it just works. I don't know of anyone having tried it before. See the ifdef in locore.S for an example of something that probably needs to be ported.

[royger]

sys/x86/xen/hvm.c

193

I see. It should work for HVM (that uses the native FreeBSD entry point). PVH that uses a different entry point will indeed need a bit of work. Will attempt to remember to look at that, shouldn't be too hard.

[royger]

Check linear address and use %u to print an uint32_t