On 01.09.2021 17:24, Juergen Gross wrote: > On 01.09.21 17:06, Jan Beulich wrote: >> 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/ ... > > Did you add earlyprintk=xen to the dom0 boot parameters?
Yes (I did mention this before) - no difference at all. I guess I'll try again, just in case I made a stupid mistake. Jan
