From: Robin Murphy <robin.murphy@arm.com>
To: Will Deacon <will@kernel.org>
Cc: Tyler Hicks <code@tyhicks.com>, Jason Gunthorpe <jgg@ziepe.ca>,
Jerry Snitselaar <jsnitsel@redhat.com>,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, Dexuan Cui <decui@microsoft.com>,
Easwar Hariharan <eahariha@linux.microsoft.com>
Subject: Re: Why is the ARM SMMU v1/v2 put into bypass mode on kexec?
Date: Tue, 2 Apr 2024 17:32:49 +0100 [thread overview]
Message-ID: <67afde12-3fed-4298-9c5e-fbb4819c52a8@arm.com> (raw)
In-Reply-To: <20240322155157.GD5634@willie-the-truck>
On 2024-03-22 3:51 pm, Will Deacon wrote:
> On Tue, Mar 19, 2024 at 06:17:39PM +0000, Robin Murphy wrote:
>> In terms of the shutdown behaviour, I think it actually works out as-is. For
>> the normal case we haven't touched GBPA, so we are truly returning to the
>> boot-time condition; in the unexpected case where SMMUEN was already enabled
>> then we'll go into an explicit GPBA abort state, but that seems a
>> not-unreasonable compromise for not preserving the entire boot-time Stream
>> Table etc., whose presence kind of implies it wouldn't have been bypassing
>> everything anyway.
>>
>> The more I look at the remaining aspect of disable_bypass for controlling
>> broken-DT behaviour the more I suspect it can't actually be useful either
>> way, especially not since default domains. I have no memory of what my
>> original reasoning might have been, so I'm inclined to just rip that all out
>> and let probe fail. I see no reason these days not to expect a broken DT to
>> leads to a broken system, especially not now with DTSchema validation.
>
> That sounds reasonable to me, although we may end up having to back it
> out if we regress systems with borked firmware :(
>
>> Then there's just the kdump warning it suppresses, of which I also have no
>> idea why it's there either, but apparently that one's on you :P
>
> I think _that_ one is because the previous (crashed) kernel won't have
> torn anything down, so there could be active DMA using translations in
> the SMMU. In that case, the crashkernel (which is running from some
> carveout) may find the SMMU enabled, but it really can't stick it into
> bypass mode because that's likely to corrupt random memory. So in that
> case, we do stick it into abort before we reinitialise it and then we
> disabling fault reporting altogether to avoid the log spam:
>
> if (is_kdump_kernel())
> enables &= ~(CR0_EVTQEN | CR0_PRIQEN)
Oh, I know why we do what we do for the kdump situation in general - it
was merely the matter of why we chose to demand that the user explicitly
tells us to do what we know is the right thing (and scream at them if
they don't), rather than to just go ahead and do the right thing anyway.
(the significance of disable_bypass for kdump is after we turn the SMMU
back on from GBPA Abort state - we don't want any ongoing traffic being
able to inadvertently bypass via an STE config either)
Cheers,
Robin.
next prev parent reply other threads:[~2024-04-02 16:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-14 7:49 Why is the ARM SMMU v1/v2 put into bypass mode on kexec? Tyler Hicks
2024-03-14 19:06 ` Tyler Hicks
2024-03-19 12:57 ` Robin Murphy
2024-03-19 15:47 ` Will Deacon
2024-03-19 17:50 ` Jason Gunthorpe
2024-03-22 15:55 ` Will Deacon
2024-03-22 19:52 ` Tyler Hicks
2024-03-19 18:17 ` Robin Murphy
2024-03-22 15:51 ` Will Deacon
2024-04-02 16:32 ` Robin Murphy [this message]
2024-03-19 19:14 ` Tyler Hicks
2024-03-22 16:06 ` Will Deacon
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=67afde12-3fed-4298-9c5e-fbb4819c52a8@arm.com \
--to=robin.murphy@arm.com \
--cc=code@tyhicks.com \
--cc=decui@microsoft.com \
--cc=eahariha@linux.microsoft.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=jsnitsel@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).