On Tue, Aug 31, 2021 at 10:53:59AM +0200, 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.
Iff you have some time could you check without the XSA applied? I have to admit I haven't been testing staging, so it's possible some breakage as slipped in (however osstest seemed fine with it). > > 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. Not sure it would help much, but maybe you can post the Xen+Linux output? Do you have iommu debug/verbose enabled to catch iommu faults? > 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. Can you dump the state of the VMCS and see where the IP points to in Linux? Thanks, Roger.
