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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

[And there was another rather basic issue to fight first (patch
 will be submitted separately): vPCI wasn't aware of hidden PCI
 devices, hitting an ASSERT(). Obviously I couldn't afford not
 having a functioning serial console.]

In the course I ran into an oom condition while populating Dom0's
RAM. Hence next some re-work of dom0_compute_nr_pages(). In turn
in the course of putting that together I did notice that PV Dom0,
when run in shadow mode, wouldn't have its shadow allocation
properly set.

1: PVH: de-duplicate mappings for first Mb of Dom0 memory
2: P2M: relax guarding of MMIO entries
3: PVH: improve Dom0 memory size calculation
4: PV: properly set shadow allocation for Dom0

Jan