Re: [PATCH v1 16/21] s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq

than that: Acked-by: Sebastian Ott seb...@linux.vnet.ibm.com Regards, Sebastian irq_set_msi_desc(msi-irq, NULL); irq_free_desc(msi-irq); msi-msg.address_lo = 0; @@ -464,6 +464,16 @@ void arch_teardown_msi_irqs(struct pci_dev *pdev

Re: [PATCH v3 22/27] s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq

On Wed, 15 Oct 2014, Yijing Wang wrote: Use MSI chip framework instead of arch MSI functions to configure MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework. Signed-off-by: Yijing Wang wangyij...@huawei.com --- Hi Sebastian, I dropped the Acked-by , because this

Re: [PATCH 16/31] s390: handle page-less SG entries

On Wed, 12 Aug 2015, Christoph Hellwig wrote: Use sg_phys() instead of page_to_phys(sg_page(sg)) so that we don't require a page structure for all DMA memory. Signed-off-by: Christoph Hellwig h...@lst.de Acked-by: Sebastian Ott seb...@linux.vnet.ibm.com --- arch/s390/pci/pci_dma.c | 20

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Fri, 12 Feb 2016, Will Deacon wrote: > On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote: > > On Thu, 11 Feb 2016 21:09:42 +0200 > > "Kirill A. Shutemov" <kir...@shutemov.name> wrote: > > > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gera

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Thu, 11 Feb 2016, Kirill A. Shutemov wrote: > On Thu, Feb 11, 2016 at 09:09:42PM +0200, Kirill A. Shutemov wrote: > > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote: > > > Hi, > > > > > > Sebastian Ott reported random kernel crashes begin

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Sat, 13 Feb 2016, Kirill A. Shutemov wrote: > Could you check if revert of fecffad25458 helps? I reverted fecffad25458 on top of 721675fcf277cf - it oopsed with: ¢ 1851.721062! Unable to handle kernel pointer dereference in virtual kernel address space ¢ 1851.721075! failing address:

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Wed, 24 Feb 2016, Martin Schwidefsky wrote: > On Tue, 23 Feb 2016 22:33:45 +0300 > "Kirill A. Shutemov" wrote: > > > On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote: > > > I'll check with Martin, maybe it is actually trivial, then we can > > > do a quick

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

Hi, On Wed, 17 Feb 2016, Kirill A. Shutemov wrote: > On Tue, Feb 16, 2016 at 05:24:44PM +0100, Gerald Schaefer wrote: > > On Mon, 15 Feb 2016 23:35:26 +0200 > > "Kirill A. Shutemov" wrote: > > > > > Is there any chance that I'll be able to trigger the bug using QEMU? > > >

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Thu, 18 Feb 2016, Kirill A. Shutemov wrote: > I worth minimizing kernel config on which you can see the bug. Things like > CONFIG_DEBUG_PAGEALLOC used to interfere with THP before. I disabled all debugging options (using arch/s390/configs/performance_defconfig) - we still chrashed. Sebastian

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Mon, 15 Feb 2016, Kirill A. Shutemov wrote: > > [ 59.851421] list_del corruption. next->prev should be 6e1eb000, > > but was 0400 > > This kinda interesting: 0x400 is TAIL_MAPPING.. Hm.. > > Could you check if you see the problem on commit 1c290f642101 and its >

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Mon, 15 Feb 2016, Kirill A. Shutemov wrote: > Just to make sure: commit 122afea9626a is fine, commit 61f5d698cc97 > crashes. Correct? Correct. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org

Re: [PATCH 0/2] sriov enablement on s390

Hello Bjorn, On Wed, 12 Sep 2018, Bjorn Helgaas wrote: > On Wed, Sep 12, 2018 at 02:34:09PM +0200, Sebastian Ott wrote: > > On s390 we currently handle SRIOV within firmware. Which means > > that the PF is under firmware control and not visible to operating > > systems. SRI

Re: [PATCH 7/9] PCI: hotplug: Drop hotplug_slot_info

obe. That seems unlikely to me, still maintainers should > review the changes carefully for this possibility. > > Signed-off-by: Lukas Wunner > Cc: Rafael J. Wysocki > Cc: Len Brown > Cc: Scott Murray > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: Gavin Shan > Cc: Sebastian Ott > Cc: Gerald Schaefer > Cc: Corentin Chary > Cc: Darren Hart > Cc: Andy Shevchenko for s390_pci_hpc.c: Acked-by: Sebastian Ott

Re: [PATCH 8/9] PCI: hotplug: Embed hotplug_slot

vate" pointer in struct hotplug_slot thereby becomes > unused, so drop it. > > Signed-off-by: Lukas Wunner > Cc: Rafael J. Wysocki > Cc: Len Brown > Cc: Scott Murray > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman > Cc: Gavin Shan &g

[PATCH 1/2] PCI/IOV: provide flag to skip VF scanning

Provide a flag to skip scanning for new VFs after SRIOV enablement. This can be set by implementations for which the VFs are already reported by other means. Signed-off-by: Sebastian Ott --- drivers/pci/iov.c | 48 include/linux/pci.h | 1 + 2

[PATCH 2/2] s390/pci: skip VF scanning

Set the flag to skip scanning for VFs after SRIOV enablement. VF creation will be triggered by the hotplug code. Signed-off-by: Sebastian Ott --- arch/s390/pci/pci.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c index 9f6f392a4461..4266a4de3160

Re: [PATCH 2/2] s390/pci: handle function enumeration after sriov enablement

On Fri, 14 Dec 2018, Christoph Hellwig wrote: > On Fri, Dec 14, 2018 at 05:12:45AM -0800, Christoph Hellwig wrote: > > On Thu, Dec 13, 2018 at 06:54:28PM +0100, Sebastian Ott wrote: > > > Implement pcibios_sriov_{add|del}_vfs as empty functions. VF > > > creation will

[PATCH 1/3] PCI/IOV: factor out sriov_add_vfs

Provide sriov_add_vfs as a wrapper to scan for VFs that cleans up after itself. This is just a code simplification. No functional change. Signed-off-by: Sebastian Ott Reviewed-by: Christoph Hellwig --- drivers/pci/iov.c | 44 +++- 1 file changed, 31

[PATCH 2/3] PCI/IOV: provide flag to skip VF scanning

Provide a flag to skip scanning for new VFs after SRIOV enablement. This can be set by implementations for which the VFs are already reported by other means. Signed-off-by: Sebastian Ott Reviewed-by: Christoph Hellwig --- drivers/pci/iov.c | 6 ++ include/linux/pci.h | 1 + 2 files

[PATCH 3/3] s390/pci: skip VF scanning

Set the flag to skip scanning for VFs after SRIOV enablement. VF creation will be triggered by the hotplug code. Signed-off-by: Sebastian Ott Reviewed-by: Christoph Hellwig --- arch/s390/pci/pci.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c

Re: [PATCH 1/2] PCI/IOV: provide flag to skip VF scanning

Hello Bjorn, On Thu, 20 Dec 2018, Bjorn Helgaas wrote: > I think the strategy is fine, but can you restructure the patches > like this: > > 1) Factor out sriov_add_vfs() and sriov_dev_vfs(). This makes no > functional change at all. > > 2) Add dev->no_vf_scan, set it in the s390

[PATCH 1/2] PCI: provide pcibios_sriov_add_vfs

Move VF detection and device creation code to weak functions such that architectures can provide a different implementation. Signed-off-by: Sebastian Ott --- drivers/pci/iov.c | 43 +++ include/linux/pci.h | 2 ++ 2 files changed, 33 insertions(+), 12

[PATCH 2/2] s390/pci: handle function enumeration after sriov enablement

Implement pcibios_sriov_{add|del}_vfs as empty functions. VF creation will be triggered by the hotplug code. Signed-off-by: Sebastian Ott --- arch/s390/pci/pci.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c index 9f6f392a4461

Re: [PATCH 0/2] sriov enablement on s390

Hello Bjorn, On Wed, 10 Oct 2018, Bjorn Helgaas wrote: > On Wed, Oct 10, 2018 at 02:55:07PM +0200, Sebastian Ott wrote: > > On Wed, 12 Sep 2018, Bjorn Helgaas wrote: > > > On Wed, Sep 12, 2018 at 02:34:09PM +0200, Sebastian Ott wrote: > > > > On s390 we currentl

Re: [PATCH 0/2] sriov enablement on s390

On Wed, 12 Sep 2018, Bjorn Helgaas wrote: > [+cc Arnd, powerpc folks] > > On Wed, Sep 12, 2018 at 02:34:09PM +0200, Sebastian Ott wrote: > > Hello Bjorn, > > > > On s390 we currently handle SRIOV within firmware. Which means > > that the PF is under firmware con

[PATCH 2/2] s390/pci: handle function enumeration after sriov enablement

Implement add_vfs|del_vfs callbacks as empty functions. VF creation will be triggered by the hotplug code. Signed-off-by: Sebastian Ott --- arch/s390/pci/pci.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c index 9381d5d98156

[PATCH 1/2] pci: provide add_vfs/del_vfs callbacks

Provide callbacks that can be used by PCI host bridge implementations to override the behavior of the generic vf detection and device creation code. Signed-off-by: Sebastian Ott --- drivers/pci/iov.c | 51 +++ include/linux/pci.h | 2 ++ 2

Re: [PATCH v5 4/6] s390/pci: add support for generic boot option iommu.dma_mode

On Tue, 9 Apr 2019, Zhen Lei wrote: > s390_iommu=strict is equivalent to iommu.dma_mode=strict. > > Signed-off-by: Zhen Lei Acked-by: Sebastian Ott

Re: [PATCH v8 3/7] s390/pci: add support for IOMMU default DMA mode build options

On Thu, 30 May 2019, Zhen Lei wrote: > The default DMA mode is LAZY on s390, this patch make it can be set to > STRICT at build time. It can be overridden by boot option. > > There is no functional change. > > Signed-off-by: Zhen Lei Acked-by: Sebastian Ott