[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
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.