Thread (29 messages) flat view 29 messages, 4 authors, 2017-08-10

Re: [PATCH 08/13] powerpc/64s: irq replay remove spurious irq reason

From: Michael Ellerman <mpe@ellerman.id.au>
Date: 2017-08-10 13:13:01

Nicholas Piggin [off-list ref] writes:
On Sun, 06 Aug 2017 09:00:32 +1000
Benjamin Herrenschmidt [off-list ref] wrote:
quoted
On Sun, 2017-08-06 at 03:02 +1000, Nicholas Piggin wrote:
quoted
HVI interrupts have always used 0x500, so remove the dead branch.  
Maybe we should fix that and "catch" in incorrect entry via 0x500
which would mean the XIVE is trying to deliver guest irqs to the OS...
I should be more clear, when I say 0x500, it is only in reference to
the constant used by the soft-irq replay. After patch 6 the replay is
sent to the 0xea0 common handler.
quoted
That can happen if some LPCR bits aren't set properly and/or KVM
doesn't pull the guest in time. I had bugs like that in my early
dev so I've been running with a b . at 0x500 for a while :-)
So that's a separate issue of hardware actually doing a 0x500. I
had this

http://patchwork.ozlabs.org/patch/750033/
Hmm, yeah I was going to merge that.

But I got side tracked by HVICE, ie. the "interrupts don't go to 0x500"
is only true if we set HVICE.

Which we currently always do, in __setup_cpu_power9(), but then we have
a DT CPU feature for it, so we really shouldn't be always enabling
HVICE, we should leave it up to the DT CPU feature code.

And then it becomes controlled by the device tree, which makes your
patch potentially wrong depending on the device tree CPU features.

Ugh.

cheers
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help