All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
Cc: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>,
	Timur Tabi <timur-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	"Goel, Sameer" <sgoel-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH] iommu/arm-smmu-v3: Set GBPA to abort all transactions
Date: Thu, 12 Apr 2018 11:55:30 +0100	[thread overview]
Message-ID: <20180412105530.GC20539@arm.com> (raw)
In-Reply-To: <7756f245-6c63-92d4-d101-4040a45b660b-5wv7dgnIgG8@public.gmane.org>

On Thu, Apr 12, 2018 at 11:17:24AM +0100, Robin Murphy wrote:
> On 11/04/18 17:54, Marc Zyngier wrote:
> >On 11/04/18 16:58, Goel, Sameer wrote:
> >>On 3/28/2018 9:00 AM, Marc Zyngier wrote:
> >>>A tangential question: can we reliably detect that the SMMU already
> >>>has valid mappings, which would indicate that we're in a pretty bad
> >>>shape already by the time we set that bit? For all we know, memory
> >>>could have been corrupted long before we hit this point, and this
> >>>patch barely narrows the window of opportunity.
> >>
> >>:) Yes that is correct. This only covers the kdump scenario. Trying
> >>to get some reliability when booting up the crash kernel. The system
> >>is already in a bad state. I don't think that this will happen in a
> >>normal scenario. But please point me to the GICv3 change and I'll
> >>have a look.
> >
> >See this:
> >https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/tree/drivers/irqchip/irq-gic-v3-its.c?h=irq/irqchip-4.17&id=6eb486b66a3094cdcd68dc39c9df3a29d6a51dd5#n3407
> 
> The nearest equivalent to that is probably the top-level SMMUEN check that
> we already have (see the diff context above). To go beyond that you'd have
> to chase the old stream table pointer and scan the whole thing looking for
> valid contexts, then potentially walk page tables within those contexts to
> check for live translations if you really wanted to be sure. That would be a
> hell of a lot of work to do in the boot path.

Yeah, please don't waste time writing a patch to do that! ;)

Will

WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] iommu/arm-smmu-v3: Set GBPA to abort all transactions
Date: Thu, 12 Apr 2018 11:55:30 +0100	[thread overview]
Message-ID: <20180412105530.GC20539@arm.com> (raw)
In-Reply-To: <7756f245-6c63-92d4-d101-4040a45b660b@arm.com>

On Thu, Apr 12, 2018 at 11:17:24AM +0100, Robin Murphy wrote:
> On 11/04/18 17:54, Marc Zyngier wrote:
> >On 11/04/18 16:58, Goel, Sameer wrote:
> >>On 3/28/2018 9:00 AM, Marc Zyngier wrote:
> >>>A tangential question: can we reliably detect that the SMMU already
> >>>has valid mappings, which would indicate that we're in a pretty bad
> >>>shape already by the time we set that bit? For all we know, memory
> >>>could have been corrupted long before we hit this point, and this
> >>>patch barely narrows the window of opportunity.
> >>
> >>:) Yes that is correct. This only covers the kdump scenario. Trying
> >>to get some reliability when booting up the crash kernel. The system
> >>is already in a bad state. I don't think that this will happen in a
> >>normal scenario. But please point me to the GICv3 change and I'll
> >>have a look.
> >
> >See this:
> >https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/tree/drivers/irqchip/irq-gic-v3-its.c?h=irq/irqchip-4.17&id=6eb486b66a3094cdcd68dc39c9df3a29d6a51dd5#n3407
> 
> The nearest equivalent to that is probably the top-level SMMUEN check that
> we already have (see the diff context above). To go beyond that you'd have
> to chase the old stream table pointer and scan the whole thing looking for
> valid contexts, then potentially walk page tables within those contexts to
> check for live translations if you really wanted to be sure. That would be a
> hell of a lot of work to do in the boot path.

Yeah, please don't waste time writing a patch to do that! ;)

Will

  parent reply	other threads:[~2018-04-12 10:55 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-28 14:39 [PATCH] iommu/arm-smmu-v3: Set GBPA to abort all transactions Timur Tabi
2018-03-28 14:39 ` Timur Tabi
2018-03-28 15:00 ` Marc Zyngier
2018-03-28 15:00   ` Marc Zyngier
2018-04-11 15:58   ` Goel, Sameer
2018-04-11 15:58     ` Goel, Sameer
     [not found]     ` <3772fb2d-01b7-4820-6d13-a0263654dabc-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-04-11 16:54       ` Marc Zyngier
2018-04-11 16:54         ` Marc Zyngier
     [not found]         ` <438a6180-fca8-d3a1-985f-e595529911f3-5wv7dgnIgG8@public.gmane.org>
2018-04-12 10:17           ` Robin Murphy
2018-04-12 10:17             ` Robin Murphy
     [not found]             ` <7756f245-6c63-92d4-d101-4040a45b660b-5wv7dgnIgG8@public.gmane.org>
2018-04-12 10:55               ` Will Deacon [this message]
2018-04-12 10:55                 ` Will Deacon
2018-04-12 11:56               ` Marc Zyngier
2018-04-12 11:56                 ` Marc Zyngier
     [not found]                 ` <265a41d4-ec3c-6697-0340-6830807ea10f-5wv7dgnIgG8@public.gmane.org>
2018-05-11 16:15                   ` Goel, Sameer
2018-05-11 16:15                     ` Goel, Sameer
2018-05-11 20:52                 ` Nate Watterson
2018-05-11 20:52                   ` Nate Watterson
     [not found] ` <1522247980-31892-1-git-send-email-timur-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-04-05 11:26   ` Will Deacon
2018-04-05 11:26     ` Will Deacon
2018-04-11 15:54     ` Goel, Sameer
2018-04-11 15:54       ` Goel, Sameer

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=20180412105530.GC20539@arm.com \
    --to=will.deacon-5wv7dgnigg8@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
    --cc=robin.murphy-5wv7dgnIgG8@public.gmane.org \
    --cc=sgoel-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=timur-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.