[FSL P50x0] KVM HV doesn't work anymore

[Nicholas Piggin]

Excerpts from Christian Zigotzky's message of June 7, 2021 5:21 pm:
> On 02 June 2021 at 01:26pm, Christian Zigotzky wrote:
>> On 20 May 2021 at 01:07am, Nicholas Piggin wrote:
>>> Hmm, okay that probably rules out those notifier changes then.
>>> Can you remind me were you able to rule these out as suspects?
>>>
>>> 8f6cc75a97d1 powerpc: move norestart trap flag to bit 0
>>> 8dc7f0229b78 powerpc: remove partial register save logic
>>> c45ba4f44f6b powerpc: clean up do_page_fault
>>> d738ee8d56de powerpc/64e/interrupt: handle bad_page_fault in C
>>> ceff77efa4f8 powerpc/64e/interrupt: Use new interrupt context 
>>> tracking scheme
>>> 097157e16cf8 powerpc/64e/interrupt: reconcile irq soft-mask state in C
>>> 3db8aa10de9a powerpc/64e/interrupt: NMI save irq soft-mask state in C
>>> 0c2472de23ae powerpc/64e/interrupt: use new interrupt return
>>> dc6231821a14 powerpc/interrupt: update common interrupt code for
>>> 4228b2c3d20e powerpc/64e/interrupt: always save nvgprs on interrupt
>>> 5a5a893c4ad8 powerpc/syscall: switch user_exit_irqoff and 
>>> trace_hardirqs_off order
>>>
>>> Thanks,
>>> Nick
>> Hi Nick,
>>
>> I tested these commits above today and all works with -smp 4. [1]
>>
>> Smp 4 still doesn't work with the RC4 of kernel 5.13 on quad core 
>> e5500 CPUs with KVM HV. I use -smp 3 currently.
>>
>> What shall I test next?
>>
>> Thanks,
>> Christian
>>
>> [1] https://forum.hyperion-entertainment.com/viewtopic.php?p=53367#p53367
> Hi All,
> 
> I tested the RC5 of kernel 5.13 today. Unfortunately the KVM HV issue 
> still exists.
> I also figured out, that '-smp 2' doesn't work either.
> 
> Summary:
> 
> -smp 1 -> works
> -smp 2 -> doesn't work
> -smp 3 -> works
> -smp 4 -> doesn't work

Sorry, I'm not able to see anything, if the KVM patches were okay and 
the 64e interrupt series. I don't know why the -smp behaviour would make

I can't think of why the -smp behaviour would make a difference except 
for a strange race. Doing another bisect might be the only way to get
to the bottom of it.

But before that you could try get some data about why the guest stops?
Get some samples of CPU registers when it gets stuck and see if you can
see if it is stuck in a loop of interupts or something.

I don't know if qemu can log much from KVM execution so you might have
to just run info registers a dozen times on each CPU (`cpu 1` will 
change to CPU 1 in the qemu monitor).

Thanks,
Nick