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

[Jan Beulich <jbeulich@xxxxxxxx>]

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