Re: panic kexec broken on ARM64?

From: Marc Zyngier <marc.zyngier@arm.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Stefan Wahren <stefan.wahren@i2se.com>,
	Matthias Brugger <mbrugger@suse.com>,
	Petr Tesarik <ptesarik@suse.cz>,
	kexec mailing list <kexec@lists.infradead.org>,
	"takahiro.akashi@linaro.org" <takahiro.akashi@linaro.org>,
	James Morse <james.morse@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: panic kexec broken on ARM64?
Date: Fri, 03 Aug 2018 07:06:53 +0100	[thread overview]
Message-ID: <86600sq8zm.wl-marc.zyngier@arm.com> (raw)
In-Reply-To: <1533224994.16128.81.camel@infradead.org>

On Thu, 02 Aug 2018 16:49:54 +0100,
David Woodhouse <dwmw2@infradead.org> wrote:
> 
> On Thu, 2018-07-05 at 11:19 +0100, Marc Zyngier wrote:
> > >> The criteria is "this irqchip requires a reset to be safely used in the
> > >> secondary kernel". This is a judgement call from the person writing the
> > >> driver.
> > > 
> > > This doesn't tell me anything more than "do it if you need it."
> > > So let me ask you in other words.
> > > Does gic driver need to provide a reset function?
> > > Whether yes or no, why do you think so?
> > 
> > Because I know the architecture and I can assess that it needs it. Case
> > in point: The RDs have memory tables. kexec without disabling LPIs, and
> > you end-up with memory corruption.
> > 
> > Sorry, but there is no magic bullet. You have to understand what you're
> > doing.
> 
> Remember, kexec and kdump are subtly different things.
> 
> In the case of an orderly kexec, sure you can go walking chains of
> interrupt controllers (and other devices) and nicely quiescing them.
> 
> In the kdump case it's different. You really want as few instructions
> as possible between realising you're going to panic, and entering the
> kdump kernel. You NMI¹ all the other cores to dump their state, and
> just GTFO.
> 
> In the kdump case you also aren't *reusing* the memory, which means
> that existing memory tables which are being accessed by hardware
> shouldn't be an issue. You can let the second kernel reset it all from
> a controlled and not-already-panicking environment.

Yes, in the kdump case, you can safely continue without experiencing
memory corruption. No, you cannot reset them, which is the whole
point. What you can do is use the LPI configuration as it is, and cope
with it (at the expense of changing memory that was under control of
the primary kernel -- let's hope you're not trying to debug
interrupt-related issues...).

See [1] which implements that and a bit more to actually support kexec
in such a configuration.

> ¹ Oops no NMI. Doh.

Care to help reviewing this[2]?

	M.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/gicv3-kdump

[2] https://lwn.net/Articles/755906/

-- 
Jazz is not dead, it just smell funny.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec