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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 01.09.2021 15:56, Roger Pau Monné wrote:
> 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).

Well, I'd rather try to use the time to find the actual issue. From
osstest being fine I'm kind of inferring this might be machine
specific, or this might be due to yet some other of the overly many
patches I'm carrying. So if I can't infer anything from the stack
once I can actually dump that, I may indeed need to bisect my pile,
which would then also include the XSA-378 patches (as I didn't have
time to re-base so far).

>>> 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?

There's no Linux output yet by that point (and either
"earlyprintk=xen" doesn't work in PVH mode, or it's even too early
for that). All Xen has to say is

(XEN) Dom0 callback via changed to Direct Vector 0xf3
(XEN) vmx.c:3265:d0v0 RDMSR 0x0000064e unimplemented
(XEN) vmx.c:3265:d0v0 RDMSR 0x00000034 unimplemented

> Do you have iommu debug/verbose enabled to catch iommu faults?

I'll try to remember to check that, but since Linux hasn't
brought up APs yet I don't think there's any device activity
just yet.

>> 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?

Both that and the register dumping I have meanwhile working tell
me that it's the HLT in default_idle(). IOW Dom0 gives the impression
of also being idle, at the first glance. The stack pointer, however,
is farther away from the stack top than I would have expected, so it
may still have entered default_idle() for other reasons.

The VMCS also told me that the last VM entry was to deliver an
interrupt at vector 0xf3 (i.e. the "callback" one).

Jan