[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 0/4] x86/PVH: Dom0 building adjustments
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? Juergen Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc Attachment:
OpenPGP_signature
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |