On 10/28/19 3:54 AM, Oliver O'Halloran wrote:
On pseries there is a bug with adding hotplugged devices to an IOMMU group.
For a number of dumb reasons fixing that bug first requires re-working how
VFs are configured on PowerNV.
Are these patches expected to land soon, or is there another fix in
On 6/12/19 2:15 PM, Shawn Anastasio wrote:
On 6/12/19 2:07 AM, Alexey Kardashevskiy wrote:
On 12/06/2019 15:05, Shawn Anastasio wrote:
On 6/5/19 11:11 PM, Shawn Anastasio wrote:
On 5/30/19 2:03 AM, Alexey Kardashevskiy wrote:
This is an attempt to allow DMA masks between 32..59 which are
On 6/18/19 1:39 AM, Alexey Kardashevskiy wrote:
On 18/06/2019 14:26, Shawn Anastasio wrote:
On 6/12/19 2:15 PM, Shawn Anastasio wrote:
On 6/12/19 2:07 AM, Alexey Kardashevskiy wrote:
On 12/06/2019 15:05, Shawn Anastasio wrote:
On 6/5/19 11:11 PM, Shawn Anastasio wrote:
On 5/30/19 2:03
uot;powerpc/dma: remove dma_nommu_mmap_coherent")
Signed-off-by: Shawn Anastasio
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/kernel/Makefile | 3 ++-
arch/powerpc/kernel/dma-common.c | 17 +
3 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644
On 7/17/19 9:59 PM, Alexey Kardashevskiy wrote:
On 18/07/2019 09:54, Shawn Anastasio wrote:
The refactor of powerpc DMA functions in commit cc17d780
("powerpc/dma: remove dma_nommu_mmap_coherent") incorrectly
changes the way DMA mappings are handled on powerpc.
Since this c
On 7/18/19 4:52 AM, Christoph Hellwig wrote:
On Thu, Jul 18, 2019 at 10:49:34AM +0200, Christoph Hellwig wrote:
On Thu, Jul 18, 2019 at 01:45:16PM +1000, Oliver O'Halloran wrote:
Other than m68k, mips, and arm64, everybody else that doesn't have
ARCH_NO_COHERENT_DMA_MMAP set uses this default i
On 7/19/19 2:06 AM, Christoph Hellwig wrote:
> What is inherently architecture specific here over the fact that
> the pgprot_* expand to architecture specific bits?
What I meant is that different architectures seem to have different
criteria for setting the different pgprot_ bits. i.e. ppc checks
On 7/22/19 7:16 AM, Michael Ellerman wrote:
Arnd Bergmann writes:
On Thu, Jul 18, 2019 at 11:52 AM Christoph Hellwig wrote:
On Thu, Jul 18, 2019 at 10:49:34AM +0200, Christoph Hellwig wrote:
On Thu, Jul 18, 2019 at 01:45:16PM +1000, Oliver O'Halloran wrote:
Other than m68k, mips, and arm
On 8/5/19 10:01 AM, Christoph Hellwig wrote:
diff --git a/include/linux/dma-noncoherent.h b/include/linux/dma-noncoherent.h
index 3813211a9aad..9ae5cee543c4 100644
--- a/include/linux/dma-noncoherent.h
+++ b/include/linux/dma-noncoherent.h
@@ -42,13 +42,8 @@ void arch_dma_free(struct device *dev,
On 8/7/19 8:04 AM, Christoph Hellwig wrote:
Actually it is typical modern Linux style to just provide a prototype
and then use "if (IS_ENABLED(CONFIG_FOO))" to guard the call(s) to it.
I see.
Also, like Will mentioned earlier, the function name isn't entirely
accurate anymore. I second the su
g
it would break them.
If anybody has more insight or a better way to fix this, please let me know.
Shawn Anastasio (2):
PCI: Introduce pcibios_fixup_dev()
powerpc/pci: Fix IOMMU setup for hotplugged devices on pseries
arch/powerpc/kernel/pci-common.c | 13 ++---
drivers/p
Introduce pcibios_fixup_dev to allow platform-specific code to perform
final setup of a PCI device after it has been registered in sysfs.
The default implementation is a no-op.
Signed-off-by: Shawn Anastasio
---
drivers/pci/probe.c | 14 ++
include/linux/pci.h | 1 +
2 files
on pseries, where
the existing behavior results in IOMMU assignment before registration.
Signed-off-by: Shawn Anastasio
---
arch/powerpc/kernel/pci-common.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel
On 9/5/19 4:08 AM, Alexey Kardashevskiy wrot>
I just tried hotplugging 3 virtio-net devices into a guest system with
v5.2 kernel and it seems working (i.e. BARs mapped, a driver is bound):
root@le-dbg:~# lspci -v | egrep -i '(virtio|Memory)'
00:00.0 Ethernet controller: Red Hat, Inc Virtio net
On 9/5/19 4:38 AM, Lukas Wunner wrote:
On Wed, Sep 04, 2019 at 11:22:13PM -0500, Shawn Anastasio wrote:
If anybody has more insight or a better way to fix this, please let me know.
Have you considered moving the invocation of pcibios_setup_device()
to pcibios_bus_add_device()?
The latter is
evice()
which will occur after all devices have been registered.
Shawn Anastasio (1):
powerpc/pci: Fix pcibios_setup_device() ordering
arch/powerpc/kernel/pci-common.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
--
2.20.1
assignment for hotplugged devices on pseries, where
the existing behavior results in IOMMU assignment before registration.
Thanks to Lukas Wunner for the suggestion.
Signed-off-by: Shawn Anastasio
---
arch/powerpc/kernel/pci-common.c | 25 +
1 file changed, 9 insertions
On 9/9/19 2:59 AM, Alexey Kardashevskiy wrote:
On 06/09/2019 05:13, Shawn Anastasio wrote:
Move PCI device setup from pcibios_add_device() and pcibios_fixup_bus() to
pcibios_bus_add_device(). This ensures that platform-specific DMA and IOMMU
setup occurs after the device has been registered
;s still a bit large.
If mpe is happy to take this as a fix for 5.4 then I'll leave it,
otherwise we might want to look at different approaches.
Thanks for fixing this Oliver!
Reviewed-by: Shawn Anastasio
On 5/6/24 12:43 PM, Jason Gunthorpe wrote:
> On Sat, May 04, 2024 at 12:33:53AM +0530, Shivaprasad G Bhat wrote:
>> We have legacy workloads using VFIO in userspace/kvm guests running
>> on downstream distro kernels. We want these workloads to be able to
>> continue running on our arch.
>
> It has
I'm a bit concerned about the removal of PROT_SAO.
From what I can see, a feature like this would be extremely useful for
emulating architectures with stronger memory models. QEMU's multi-
threaded TCG project in particular looks like it would be a good
candidate, since as far as I'm aware it is
On 8/18/20 2:11 AM, Nicholas Piggin wrote> Very reasonable point.
The problem we're trying to get a handle on is live partition migration
where a running guest might be using SAO then get migrated to a P10. I
don't think we have a good way to handle this case. Potentially the
hypervisor could re
fig option, PPC_PROT_SAO_LPAR was added to
allow users to explicitly enable it if they will not be running
in an environment where this is a conern.
Shawn Anastasio (2):
Revert "powerpc/64s: Remove PROT_SAO support"
powerpc/64s: Disallow PROT_SAO in LPARs by default
arch/powerpc/Kconfig
This reverts commit 5c9fa16e8abd342ce04dc830c1ebb2a03abf6c05.
Since PROT_SAO can still be useful for certain classes of software,
reintroduce it. Concerns about guest migration for LPARs using SAO
will be addressed next.
Signed-off-by: Shawn Anastasio
---
arch/powerpc/include/asm/book3s/64
Since migration of guests using SAO to ISA 3.1 hosts may cause issues,
disable PROT_SAO in LPARs by default and introduce a new Kconfig option
PPC_PROT_SAO_LPAR to allow users to enable it if desired.
Signed-off-by: Shawn Anastasio
---
arch/powerpc/Kconfig| 12
arch
On 8/21/20 5:37 AM, Nicholas Piggin wrote:> I think this should be okay.
Could you also update the selftest to skip
if we have PPC_FEATURE2_ARCH_3_1 set?
Sure. I'll send out a v2 shortly with another patch for this.
Thanks,
Nick
Thanks,
Shawn
he flag is disabled by default
in LPARs. A new config option, PPC_PROT_SAO_LPAR was added to
allow users to explicitly enable it if they will not be running
in an environment where this is a conern.
Shawn Anastasio (3):
Revert "powerpc/64s: Remove PROT_SAO support"
powerpc/64s: Disallow
Since migration of guests using SAO to ISA 3.1 hosts may cause issues,
disable PROT_SAO in LPARs by default and introduce a new Kconfig option
PPC_PROT_SAO_LPAR to allow users to enable it if desired.
Signed-off-by: Shawn Anastasio
---
arch/powerpc/Kconfig| 12
arch
Since SAO support was removed from ISA 3.1, skip the
prot_sao test if PPC_FEATURE2_ARCH_3_1 is set.
Signed-off-by: Shawn Anastasio
---
tools/testing/selftests/powerpc/mm/prot_sao.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/powerpc/mm
This reverts commit 5c9fa16e8abd342ce04dc830c1ebb2a03abf6c05.
Since PROT_SAO can still be useful for certain classes of software,
reintroduce it. Concerns about guest migration for LPARs using SAO
will be addressed next.
Signed-off-by: Shawn Anastasio
---
arch/powerpc/include/asm/book3s/64
Implement pcibios_default_alignment for pseries so that
resources are page-aligned. The main benefit of this is being
able to map any resource from userspace via mechanisms like VFIO.
This is identical to powernv's implementation.
Signed-off-by: Shawn Anastasio
---
arch/powerpc/plat
powernv by commit 382746376993 ("powerpc/powernv: Override
pcibios_default_alignment() to force PCI devices to be page aligned")
Signed-off-by: Shawn Anastasio
---
arch/powerpc/include/asm/machdep.h | 3 +++
arch/powerpc/kernel/pci-common.c | 9 +
arch/powerpc
is behavior is maintained by the
default implementation of pcibios_ignore_alignment_request.
Signed-off-by: Shawn Anastasio
---
drivers/pci/pci.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 766f5779db92..e7a925f2188e
-by: Shawn Anastasio
---
arch/powerpc/include/asm/machdep.h | 3 +--
arch/powerpc/kernel/pci_64.c | 4
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index 2f0ca6560e47..2fbfaa9176ed 100644
--- a/arch
igned").
Feedback is appreciated.
Thanks,
Shawn
Shawn Anastasio (3):
PCI: Introduce pcibios_ignore_alignment_request
powerpc/64: Enable pcibios_after_init hook on ppc64
powerpc/pseries: Allow user-specified PCI resource alignment after
init
arch/powerpc/include/asm/machdep.
be extended to provide page-aligned
resources by default for hotplugged devices, similar to what is done
on powernv by commit 382746376993 ("powerpc/powernv: Override
pcibios_default_alignment() to force PCI devices to be page aligned").
Feedback is appreciated.
Thanks,
Shawn
Shawn An
-by: Shawn Anastasio
---
arch/powerpc/include/asm/machdep.h | 3 +--
arch/powerpc/kernel/pci_64.c | 4
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index 2f0ca6560e47..2fbfaa9176ed 100644
--- a/arch
powernv by commit 382746376993 ("powerpc/powernv: Override
pcibios_default_alignment() to force PCI devices to be page aligned")
Signed-off-by: Shawn Anastasio
---
arch/powerpc/include/asm/machdep.h | 3 +++
arch/powerpc/kernel/pci-common.c | 9 +
arch/powerpc
is behavior is maintained by the
default implementation of pcibios_ignore_alignment_request.
Signed-off-by: Shawn Anastasio
---
drivers/pci/pci.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8abc843b1615..8207a09085d1
is behavior is maintained by the
default implementation of pcibios_ignore_alignment_request.
Signed-off-by: Shawn Anastasio
---
drivers/pci/pci.c | 9 +++--
include/linux/pci.h | 1 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index
powernv by commit 382746376993 ("powerpc/powernv: Override
pcibios_default_alignment() to force PCI devices to be page aligned")
Signed-off-by: Shawn Anastasio
---
arch/powerpc/include/asm/machdep.h | 3 +++
arch/powerpc/kernel/pci-common.c | 9 +
arch/powerpc
to be page aligned").
Feedback is appreciated.
Thanks,
Shawn
Shawn Anastasio (3):
PCI: Introduce pcibios_ignore_alignment_request
powerpc/64: Enable pcibios_after_init hook on ppc64
powerpc/pseries: Allow user-specified PCI resource alignment after
init
arch/powerpc/include/asm
-by: Shawn Anastasio
---
arch/powerpc/include/asm/machdep.h | 3 +--
arch/powerpc/kernel/pci_64.c | 4
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index 2f0ca6560e47..2fbfaa9176ed 100644
--- a/arch
powernv by commit 382746376993 ("powerpc/powernv: Override
pcibios_default_alignment() to force PCI devices to be page aligned")
Signed-off-by: Shawn Anastasio
---
arch/powerpc/include/asm/machdep.h | 3 +++
arch/powerpc/kernel/pci-common.c | 9 +
arch/powerpc
pc/powernv: Override
pcibios_default_alignment() to force PCI devices to be page aligned").
Feedback is appreciated.
Thanks,
Shawn
Shawn Anastasio (3):
PCI: Introduce pcibios_ignore_alignment_request
powerpc/64: Enable pcibios_after_init hook on ppc64
powerpc/pseries: Allow use
is behavior is maintained by the
default implementation of pcibios_ignore_alignment_request.
Signed-off-by: Shawn Anastasio
---
drivers/pci/pci.c | 9 +++--
include/linux/pci.h | 1 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index
-by: Shawn Anastasio
---
arch/powerpc/include/asm/machdep.h | 3 +--
arch/powerpc/kernel/pci_64.c | 4
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index 2f0ca6560e47..2fbfaa9176ed 100644
--- a/arch
On 5/27/19 11:01 PM, Oliver wrote:
On Tue, May 28, 2019 at 8:56 AM Shawn Anastasio wrote:
Hello all,
This patch set implements support for user-specified PCI resource
alignment on the pseries platform for hotplugged PCI devices.
Currently on pseries, PCI resource alignments specified with
On 5/28/19 12:36 AM, Oliver wrote:
On Tue, May 28, 2019 at 2:03 PM Shawn Anastasio wrote:
Introduce a new pcibios function pcibios_ignore_alignment_request
which allows the PCI core to defer to platform-specific code to
determine whether or not to ignore alignment requests for PCI
On 5/28/19 1:27 AM, Alexey Kardashevskiy wrote:
On 28/05/2019 15:36, Oliver wrote:
On Tue, May 28, 2019 at 2:03 PM Shawn Anastasio wrote:
Introduce a new pcibios function pcibios_ignore_alignment_request
which allows the PCI core to defer to platform-specific code to
determine whether
On 5/30/19 1:55 AM, Sam Bobroff wrote:
On Tue, May 28, 2019 at 03:36:34PM +1000, Oliver wrote:
On Tue, May 28, 2019 at 2:03 PM Shawn Anastasio wrote:
Introduce a new pcibios function pcibios_ignore_alignment_request
which allows the PCI core to defer to platform-specific code to
determine
On 5/29/19 10:39 PM, Alexey Kardashevskiy wrote:
On 28/05/2019 17:39, Shawn Anastasio wrote:
On 5/28/19 1:27 AM, Alexey Kardashevskiy wrote:
On 28/05/2019 15:36, Oliver wrote:
On Tue, May 28, 2019 at 2:03 PM Shawn Anastasio
wrote:
Introduce a new pcibios function
On 5/30/19 10:56 PM, Alexey Kardashevskiy wrote:
On 31/05/2019 08:49, Shawn Anastasio wrote:
On 5/29/19 10:39 PM, Alexey Kardashevskiy wrote:
On 28/05/2019 17:39, Shawn Anastasio wrote:
On 5/28/19 1:27 AM, Alexey Kardashevskiy wrote:
On 28/05/2019 15:36, Oliver wrote:
On Tue, May
On 6/3/19 3:35 AM, Alexey Kardashevskiy wrote:
On 03/06/2019 15:02, Alexey Kardashevskiy wrote:
On 03/06/2019 12:23, Shawn Anastasio wrote:
On 5/30/19 10:56 PM, Alexey Kardashevskiy wrote:
On 31/05/2019 08:49, Shawn Anastasio wrote:
On 5/29/19 10:39 PM, Alexey Kardashevskiy wrote
p; 0x4000)
flags |= IORESOURCE_PREFETCH
I have confirmed that this fixes the case with PCI_PROBE_ONLY
disabled and a ppc_md.pcibios_default_alignment implementation that
returns PAGE_SIZE.
Reviewed-by: Shawn Anastasio
: [PE# 00] Enabling 64-bit DMA bypass
```
Tested-by: Shawn Anastasio
On 6/5/19 11:11 PM, Shawn Anastasio wrote:
On 5/30/19 2:03 AM, Alexey Kardashevskiy wrote:
This is an attempt to allow DMA masks between 32..59 which are not large
enough to use either a PHB3 bypass mode or a sketchy bypass. Depending
on the max order, up to 40 is usually available.
This is
On 6/12/19 1:16 AM, Oliver O'Halloran wrote:
On Wed, Jun 12, 2019 at 3:06 PM Shawn Anastasio wrote:
On 6/5/19 11:11 PM, Shawn Anastasio wrote:
On 5/30/19 2:03 AM, Alexey Kardashevskiy wrote:
This is an attempt to allow DMA masks between 32..59 which are not large
enough to use either a
On 6/12/19 2:07 AM, Alexey Kardashevskiy wrote:
On 12/06/2019 15:05, Shawn Anastasio wrote:
On 6/5/19 11:11 PM, Shawn Anastasio wrote:
On 5/30/19 2:03 AM, Alexey Kardashevskiy wrote:
This is an attempt to allow DMA masks between 32..59 which are not large
enough to use either a PHB3 bypass
h Kumar K.V"
> Cc: Bjorn Helgaas
> Cc: Gaurav Batra
> Cc: Nathan Lynch
> Cc: Brian King
>
> Signed-off-by: Krishna Kumar
As with v1, I can confirm that this patch solves the panic encountered
when hotplugging PCIe bridges on POWER9.
Tested-by: Shawn Anastasio
Thanks,
Shawn
King
>
> Signed-off-by: Krishna Kumar
Other than the case with NVMe devices failing that we discussed in v1's
thread, I can confirm that this patch resolves many of the issues we've
encountered with PCIe hotplug on POWER9.
Tested-by: Shawn Anastasio
Thanks,
Shawn
can confirm that it fixes the panics
when hotplugging PCIe bridges.
Tested-by: Shawn Anastasio
Thanks,
Shawn
Hi Michael,
On 6/27/24 11:48 PM, Michael Ellerman wrote:
> Was the panic reported anywhere? So we can link to the report in the
> commit.
It was indeed -- here is the link to the thread from last December:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2023-December/267034.html
> cheers
Thanks
Hi all,
Just wanted to check in and let the community know that Raptor
Engineering will be officially dedicating development resources towards
maintaining, developing, and testing the existing Linux KVM facilities
for PowerNV machines.
To this end, we have developed a publicly-accessible CI/CD sy
Hi Alex,
On 1/7/25 5:45 AM, Alex Williamson wrote
> Hi,
>
> What are you supposing the value to the community is for a CI pipeline
> that always fails? Are you hoping the community will address the
> failing tests or monitor the failures to try to make them not become
> worse?
The failing tests
65 matches
Mail list logo
