Re: [PATCH 0/4] x86/PVH: Dom0 building adjustments

[Jan Beulich <jbeulich@xxxxxxxx>]

On 30.08.2021 15:01, Jan Beulich wrote:
> The code building PVH Dom0 made use of sequences of P2M changes
> which are disallowed as of XSA-378. First of all population of the
> first Mb of memory needs to be redone. Then, largely as a
> workaround, checking introduced by XSA-378 needs to be slightly
> relaxed.
> 
> Note that with these adjustments I get Dom0 to start booting on my
> development system, but the Dom0 kernel then gets stuck. Since it
> was the first time for me to try PVH Dom0 in this context (see
> below for why I was hesitant), I cannot tell yet whether this is
> due further fallout from the XSA, or some further unrelated
> problem. Dom0's BSP is in VPF_blocked state while all APs are
> still in VPF_down. The '0' debug key, unhelpfully, doesn't produce
> any output, so it's non-trivial to check whether (like PV likes to
> do) Dom0 has panic()ed without leaving any (visible) output.

Having made '0' work at least partly, I can now see that Dom0's
vCPU0 enters its idle loop after having gone through all normal
initialization. Clearly certain things must not have worked as
intended (no APs booted, no drivers loaded afaict), but I'm
having a hard time seeing how to find out what that might be
when there's no output at all. PV Dom0 does not require any
special command line option to do output to both the VGA console
and through hvc_xen (making its output also go to the serial
log) - is this perhaps different for PVH? I couldn't find
anything under docs/ ...

Jan