From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
To: Marc Zyngier <maz@kernel.org>, mark.rutland@arm.com
Cc: Catalin Marinas <catalin.marinas@arm.com>,
will Deacon <will@kernel.org>,
"Michael Kelley (LINUX)" <mikelley@microsoft.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Russell King <linux@armlinux.org.uk>,
Ard Biesheuvel <ardb@kernel.org>,
broonie@kernel.org,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>
Subject: Re: Should arm64 have a custom crash shutdown handler?
Date: Thu, 5 May 2022 09:44:25 -0300 [thread overview]
Message-ID: <92645c41-96fd-2755-552f-133675721a24@igalia.com> (raw)
In-Reply-To: <874k24igjf.wl-maz@kernel.org>
On 05/05/2022 04:29, Marc Zyngier wrote:
> [...]
> Not having any 'machine_ops' indirection was a conscious decision on
> arm64, if only to avoid the nightmare that 32bit was at a time with
> every single platform doing their own stuff. Introducing them would
> not be an improvement, but simply the admission that hypervisors are
> simply too broken for words. And I don't buy the "but x86 has it!"
> argument. x86 is a nightmare of PV mess that we can happily ignore,
> because we don't do PV for core operations at all.
>
> If something has to be done to quiesce the system, it probably is
> related to the system topology, and must be linked to it. We already
> have these requirements in order to correctly stop ongoing DMA, shut
> down IOMMUs, and other similar stuff. What other requirements does
> your favourite hypervisor have?
>
Thanks Marc and Mark for the details. I agree with most part of it, and
in fact panic notifiers was the trigger for this discussion (and they
are in fact used for this purpose to some extent in Hyper-V).
The idea of having this custom handler from kexec comes from Hyper-V
discussion - I feel it's better to show the code, so please take a look
at functions: hv_machine_crash_shutdown()
[arch/x86/kernel/cpu/mshyperv.c] and the one called from there,
hv_crash_handler() [drivers/hv/vmbus_drv.c].
These routines perform last minute clean-ups, right before kdump/kexec
happens, but *after* the panic notifiers. It seems there is no way to
accomplish that without architecture involvement or core kexec code
pollution heh
Anyway, the idea here was to gather a feedback on how "receptive" arm64
community would be to allow such customization, appreciated your feedback =)
Cheers,
Guilherme
next prev parent reply other threads:[~2022-05-05 12:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-04 20:00 Should arm64 have a custom crash shutdown handler? Guilherme G. Piccoli
2022-05-05 7:29 ` Marc Zyngier
2022-05-05 12:44 ` Guilherme G. Piccoli [this message]
2022-05-05 12:53 ` Mark Rutland
2022-05-05 13:05 ` Guilherme G. Piccoli
2022-05-05 13:15 ` Mark Rutland
2022-05-05 13:19 ` Guilherme G. Piccoli
2022-05-05 13:52 ` Vitaly Kuznetsov
2022-05-05 14:07 ` Guilherme G. Piccoli
2022-05-05 14:31 ` Mark Rutland
2022-05-05 14:51 ` Vitaly Kuznetsov
2022-05-06 11:01 ` Mark Rutland
2022-05-30 1:51 ` Michael Kelley (LINUX)
2022-05-05 11:10 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=92645c41-96fd-2755-552f-133675721a24@igalia.com \
--to=gpiccoli@igalia.com \
--cc=ardb@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=mikelley@microsoft.com \
--cc=vkuznets@redhat.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox