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 'd' 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.
Correction: I did mean '0' here, producing merely (XEN) '0' pressed -> dumping Dom0's registers (XEN) *** Dumping Dom0 vcpu#0 state: *** (XEN) *** Dumping Dom0 vcpu#1 state: *** (XEN) *** Dumping Dom0 vcpu#2 state: *** (XEN) *** Dumping Dom0 vcpu#3 state: *** 'd' output supports the "system is idle" that was also visible from 'q' output. Jan
