linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-mm@kvack.org, linuxppc-dev@ozlabs.org,
	Gavin Shan <gwshan@linux.vnet.ibm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH RESEND v2 7/7] PCI/hotplug: PowerPC PowerNV PCI hotplug driver
Date: Thu, 19 Feb 2015 08:03:13 +1100	[thread overview]
Message-ID: <1424293393.26254.19.camel@kernel.crashing.org> (raw)
In-Reply-To: <CAErSpo6vMyy2SoqZ4ca2D_BUxd3J4W5jASsQu0NM9opFzR5mfg@mail.gmail.com>

On Wed, 2015-02-18 at 08:30 -0600, Bjorn Helgaas wrote:
> 
> So the hypervisor call that removes the device from the partition will
> fail if there are any translations that reference the memory of the
> device.
> 
> Let me go through this in excruciating detail to see if I understand
> what's going on:
> 
>   - PCI core enumerates device D1
>   - PCI core sets device D1 BAR 0 = 0x1000
>   - driver claims D1
>   - driver ioremaps 0x1000 at virtual address V
>   - translation V -> 0x1000 is in TLB
>   - driver iounmaps V (but V -> 0x1000 translation may remain in TLB)
>   - driver releases D1
>   - hot-remove D1 (without vm_unmap_aliases(), hypervisor would fail
> this)
>   - it would be a bug to reference V here, but if we did, the
> virt-to-phys translation would succeed and we'd have a Master Abort or
> Unsupported Request on PCI/PCIe
>   - hot-add D2
>   - PCI core enumerates device D2
>   - PCI core sets device D2 BAR 0 = 0x1000
>   - it would be a bug to reference V here (before ioremapping), but if
> we did, the reference would reach D2
> 
> I don't see anything hypervisor-specific here except for the fact that
> the hypervisor checks for existing translations and most other
> platforms don't.  But it seems like the unexpected PCI aborts could
> happen on any platform.

Well, only if we incorrectly dereferenced an ioremap'ed address for
which the driver who owns it is long gone so fairly unlikely. I'm not
saying you shouldn't put the vm_unmap_aliases() in the generic unplug
code, I wouldn't mind that, but I don't think we have a nasty bug to
squash here :)

> Are we saying that those PCI aborts are OK, since it's a bug to make
> those references in the first place?  Or would we rather take a TLB
> miss fault instead so the references never make it to PCI?

I think a miss fault which is basically a page fault -> oops is
preferable for debugging (after all that MMIO might hvae been reassigned
to another device, so that abort might actually instead turn into
writing to the wrong device... bad).

However I also think the scenario is very unlikely.

> I would think there would be similar issues when unmapping and
> re-mapping plain old physical memory.  But I don't see
> vm_unmap_aliases() calls there, so those issues must be handled
> differently.  Should we handle this PCI hotplug issue the same way we
> handle RAM?

If we don't have a vm_unmap_aliases() in the memory unplug path we
probably have a bug on those HVs too :-)

Cheers,
Ben.

  reply	other threads:[~2015-02-18 21:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-17  7:13 [PATCH RESEND v2 0/7] powerpc/powernv: Unified PCI slot reset and hotplug Gavin Shan
2015-02-17  7:13 ` [PATCH RESEND v2 1/7] powerpc/powernv: Use PCI slot reset infrastructure Gavin Shan
2015-02-17  7:13 ` [PATCH RESEND v2 2/7] powerpc/powernv: Issue fundamental reset if required Gavin Shan
2015-02-17  7:13 ` [PATCH RESEND v2 3/7] powerpc/pci: Move pcibios_find_pci_bus() around Gavin Shan
2015-02-17  7:13 ` [PATCH RESEND v2 4/7] powerpc/pci: Don't scan empty slot Gavin Shan
2015-02-17  7:13 ` [PATCH RESEND v2 5/7] powerpc/powernv: Introduce pnv_pci_poll() Gavin Shan
2015-02-17  7:13 ` [PATCH RESEND v2 6/7] powerpc/powernv: Functions to retrieve PCI slot status Gavin Shan
2015-02-17  7:13 ` [PATCH RESEND v2 7/7] PCI/hotplug: PowerPC PowerNV PCI hotplug driver Gavin Shan
2015-02-17 22:09   ` Bjorn Helgaas
2015-02-18  0:16     ` Gavin Shan
2015-02-18  0:30       ` Benjamin Herrenschmidt
2015-02-18 14:30         ` Bjorn Helgaas
2015-02-18 21:03           ` Benjamin Herrenschmidt [this message]
2015-02-17 21:44 ` [PATCH RESEND v2 0/7] powerpc/powernv: Unified PCI slot reset and hotplug Stewart Smith
2015-02-17 22:26   ` Gavin Shan

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=1424293393.26254.19.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=gwshan@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.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 NNTP newsgroup(s).