[PATCH 0/2] x86: per-device dma_mapping_ops - Kernel

This is a discussion on [PATCH 0/2] x86: per-device dma_mapping_ops - Kernel ; This patchset adds per-device dma_mapping_ops support for CONFIG_X86_64 like POWER architecture does. This change enables us to cleanly fix the Calgary IOMMU issue that some devices are not behind the IOMMU [1]. It also would be helpful to handle KVM ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 28

Thread: [PATCH 0/2] x86: per-device dma_mapping_ops

  1. [PATCH 0/2] x86: per-device dma_mapping_ops

    This patchset adds per-device dma_mapping_ops support for
    CONFIG_X86_64 like POWER architecture does. This change enables us to
    cleanly fix the Calgary IOMMU issue that some devices are not behind
    the IOMMU [1]. It also would be helpful to handle KVM PCI passthrough.

    A pointer to dma_mapping_ops to struct dev_archdata is added. If the
    pointer is non NULL, DMA operations in asm/dma-mapping.h use it. If
    it's NULL, the system-wide dma_ops pointer is used as before.

    The major obstacle is that dma_mapping_error doesn't take a pointer to
    the device unlike other DMA operations. So x86 can't have
    dma_mapping_ops per device. Note all the POWER IOMMUs use the same
    dma_mapping_error function so this is not a problem for POWER but x86
    IOMMUs use different dma_mapping_error functions.

    The first patch adds the device argument to dma_mapping_error. The
    patch is trivial but large since it touches lots of drivers and
    dma-mapping.h in all the architecture.

    [1] http://lkml.org/lkml/2008/5/8/423


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH 1/2] add the device argument to dma_mapping_error

    On Tue, 13 May 2008 15:04:51 +0900 FUJITA Tomonori wrote:

    > dma_mapping_error doesn't take a pointer to the device unlike other
    > DMA operations. So we can't have dma_mapping_ops per device.
    >
    > Note that POWER already has dma_mapping_ops per device but all the
    > POWER IOMMUs use the same dma_mapping_error function. x86 IOMMUs use
    > different dma_mapping_error functions. So dma_mapping_error needs the
    > device argument.
    >
    > Signed-off-by: FUJITA Tomonori
    > ---
    > arch/arm/common/dmabounce.c | 2 +-
    > arch/ia64/hp/common/hwsw_iommu.c | 5 ++-
    > arch/ia64/hp/common/sba_iommu.c | 2 +-
    > arch/ia64/sn/pci/pci_dma.c | 2 +-
    > arch/mips/mm/dma-default.c | 2 +-
    > arch/powerpc/platforms/cell/celleb_scc_pciex.c | 2 +-
    > arch/powerpc/platforms/cell/spider-pci.c | 2 +-
    > arch/powerpc/platforms/iseries/mf.c | 2 +-
    > arch/x86/kernel/pci-gart_64.c | 1 -
    > arch/x86/kernel/pci-nommu.c | 2 +-
    > drivers/firewire/fw-iso.c | 2 +-
    > drivers/firewire/fw-ohci.c | 2 +-
    > drivers/firewire/fw-sbp2.c | 8 +++---
    > drivers/infiniband/hw/ipath/ipath_sdma.c | 2 +-
    > drivers/infiniband/hw/ipath/ipath_user_sdma.c | 6 ++--
    > drivers/infiniband/hw/mthca/mthca_eq.c | 2 +-
    > drivers/media/dvb/pluto2/pluto2.c | 2 +-
    > drivers/net/arm/ep93xx_eth.c | 4 +-
    > drivers/net/b44.c | 22 +++++++++-------
    > drivers/net/bnx2x.c | 2 +-
    > drivers/net/e100.c | 2 +-
    > drivers/net/e1000e/ethtool.c | 4 +-
    > drivers/net/e1000e/netdev.c | 11 ++++---
    > drivers/net/ibmveth.c | 32 ++++++++++++-----------
    > drivers/net/iseries_veth.c | 4 +-
    > drivers/net/mlx4/eq.c | 2 +-
    > drivers/net/pasemi_mac.c | 6 ++--
    > drivers/net/qla3xxx.c | 12 ++++----
    > drivers/net/sfc/rx.c | 4 +-
    > drivers/net/sfc/tx.c | 2 +-
    > drivers/net/spider_net.c | 4 +-
    > drivers/net/tc35815.c | 4 +-
    > drivers/net/wireless/ath5k/base.c | 4 +-
    > drivers/net/wireless/b43/dma.c | 2 +-
    > drivers/net/wireless/b43legacy/dma.c | 2 +-
    > drivers/scsi/ibmvscsi/ibmvscsi.c | 4 +-
    > drivers/scsi/ibmvscsi/ibmvstgt.c | 2 +-
    > drivers/scsi/ibmvscsi/rpa_vscsi.c | 2 +-
    > drivers/spi/atmel_spi.c | 4 +-
    > drivers/spi/au1550_spi.c | 6 ++--
    > drivers/spi/omap2_mcspi.c | 4 +-
    > drivers/spi/pxa2xx_spi.c | 4 +-
    > drivers/spi/spi_imx.c | 6 ++--
    > include/asm-alpha/dma-mapping.h | 6 ++--
    > include/asm-alpha/pci.h | 2 +-
    > include/asm-arm/dma-mapping.h | 2 +-
    > include/asm-avr32/dma-mapping.h | 2 +-
    > include/asm-cris/dma-mapping.h | 2 +-
    > include/asm-frv/dma-mapping.h | 2 +-
    > include/asm-generic/dma-mapping-broken.h | 2 +-
    > include/asm-generic/dma-mapping.h | 4 +-
    > include/asm-generic/pci-dma-compat.h | 4 +-
    > include/asm-ia64/machvec.h | 2 +-
    > include/asm-m68k/dma-mapping.h | 2 +-
    > include/asm-mips/dma-mapping.h | 2 +-
    > include/asm-mn10300/dma-mapping.h | 2 +-
    > include/asm-parisc/dma-mapping.h | 2 +-
    > include/asm-powerpc/dma-mapping.h | 2 +-
    > include/asm-sh/dma-mapping.h | 2 +-
    > include/asm-sparc/pci.h | 3 +-
    > include/asm-sparc64/dma-mapping.h | 2 +-
    > include/asm-sparc64/pci.h | 5 ++-
    > include/asm-v850/pci.h | 2 +-
    > include/asm-x86/dma-mapping.h | 7 +++--
    > include/asm-x86/swiotlb.h | 2 +-
    > include/asm-xtensa/dma-mapping.h | 2 +-
    > include/linux/i2o.h | 2 +-
    > include/rdma/ib_verbs.h | 2 +-
    > lib/swiotlb.c | 4 +-
    > 69 files changed, 140 insertions(+), 132 deletions(-)


    Seems to be missing updates to Documentation/DMA-API.txt ??

    ---
    ~Randy
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH 2/2] x86: per-device dma_mapping_ops support

    On Tue, May 13, 2008 at 03:04:52PM +0900, FUJITA Tomonori wrote:
    > This adds per-device dma_mapping_ops support for CONFIG_X86_64.
    >
    > A pointer to dma_mapping_ops to struct dev_archdata is added. If the
    > pointer is non NULL, DMA operations in asm/dma-mapping.h use it. If
    > it's NULL, the system-wide dma_ops pointer is used as before.
    >
    > Signed-off-by: FUJITA Tomonori


    Acked-by: Muli Ben-Yehuda

    Cheers,
    Muli
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH 0/2] x86: per-device dma_mapping_ops

    On Tue, May 13, 2008 at 03:04:50PM +0900, FUJITA Tomonori wrote:

    > This patchset adds per-device dma_mapping_ops support for
    > CONFIG_X86_64 like POWER architecture does. This change enables us
    > to cleanly fix the Calgary IOMMU issue that some devices are not
    > behind the IOMMU [1]. It also would be helpful to handle KVM PCI
    > passthrough.


    Awesome! Much needed, thank you for doing this.

    Cheers,
    Muli


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH 1/2] add the device argument to dma_mapping_error

    On Tue, 13 May 2008 08:39:01 -0700
    Randy Dunlap wrote:

    > On Tue, 13 May 2008 15:04:51 +0900 FUJITA Tomonori wrote:
    >
    > > dma_mapping_error doesn't take a pointer to the device unlike other
    > > DMA operations. So we can't have dma_mapping_ops per device.
    > >
    > > Note that POWER already has dma_mapping_ops per device but all the
    > > POWER IOMMUs use the same dma_mapping_error function. x86 IOMMUs use
    > > different dma_mapping_error functions. So dma_mapping_error needs the
    > > device argument.
    > >
    > > Signed-off-by: FUJITA Tomonori


    (snip)

    > Seems to be missing updates to Documentation/DMA-API.txt ??


    Oops, I'll post an updated version against -mm soon.

    Thanks,
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH 0/2] x86: per-device dma_mapping_ops

    On Wed, 14 May 2008 08:49:24 +0300
    Muli Ben-Yehuda wrote:

    > On Tue, May 13, 2008 at 03:04:50PM +0900, FUJITA Tomonori wrote:
    >
    > > This patchset adds per-device dma_mapping_ops support for
    > > CONFIG_X86_64 like POWER architecture does. This change enables us
    > > to cleanly fix the Calgary IOMMU issue that some devices are not
    > > behind the IOMMU [1]. It also would be helpful to handle KVM PCI
    > > passthrough.

    >
    > Awesome! Much needed, thank you for doing this.


    No problem. Well, as you know, it's just a base. We need more work to
    solve the problems on the top of this.

    I'd like to have a mechanism to register a hook called when a new pci
    (or dma capable) device is created. It enables IOMMUs to set up an
    appropriate dma_mapping_ops per device. It could also enables us to
    simplify the IOMMUs code to initilize devices at startup (for exmple,
    intel-iommu checks all the pci devices and creates a domain per device
    if necessary).

    I'll post an updated version against -mm. If people seems to be fine
    with per-device dma_mapping_ops, then I'll work on further issues.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH 0/2] x86: per-device dma_mapping_ops

    On Thu, 2008-05-15 at 10:12 +0900, FUJITA Tomonori wrote:
    > On Wed, 14 May 2008 08:49:24 +0300
    > Muli Ben-Yehuda wrote:
    >
    > > On Tue, May 13, 2008 at 03:04:50PM +0900, FUJITA Tomonori wrote:


    > > Awesome! Much needed, thank you for doing this.

    >
    > No problem. Well, as you know, it's just a base. We need more work to
    > solve the problems on the top of this.

    Yes thank you!
    >
    > I'd like to have a mechanism to register a hook called when a new pci
    > (or dma capable) device is created. It enables IOMMUs to set up an
    > appropriate dma_mapping_ops per device. It could also enables us to
    > simplify the IOMMUs code to initilize devices at startup (for exmple,
    > intel-iommu checks all the pci devices and creates a domain per device
    > if necessary).

    I wanted to try and create a test version of this, at least for the
    calgary side, but ran into an error with this patch set:

    Fusion MPT SAS Host driver 3.04.06
    ACPI: PCI Interrupt 0000:34:00.0[A] -> GSI 142 (level, low) -> IRQ 142
    mptbase: ioc0: Initiating bringup
    ioc0: LSISAS1078 C1: Capabilities={Initiator}
    mptbase: ioc0: PCI-MSI enabled
    Calgary: DMA error on CalIOC2 PHB 0x33
    Calgary: 0x02000000@CSR 0x00000000@PLSSR 0xb0008000@CSMR 0x00000000@MCK
    Calgary: 0x00000000@0x810 0xfee0c000@0x820 0x00000000@0x830
    0x00000000@0x840 0x03804a00@0x850 0x00000000@0x860 0x00000000@0x870
    Calgary: 0x00000000@0xcb0
    mptbase: ioc0: Initiating recovery
    mptbase: ioc0: WARNING - Unexpected doorbell active!
    mptbase: ioc0: WARNING - NOT READY!
    mptbase: ioc0: WARNING - Cannot recover rc = -1!
    mptbase: ioc0: WARNING - Firmware Reload FAILED!
    Clocksource tsc unstable (delta = 48333779773 ns)

    Not sure what is causing this error, but will keep digging. Any ideas?

    --Alexis

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [PATCH 0/2] x86: per-device dma_mapping_ops

    On Wed, 14 May 2008 19:00:13 -0700
    Alexis Bruemmer wrote:

    > On Thu, 2008-05-15 at 10:12 +0900, FUJITA Tomonori wrote:
    > > On Wed, 14 May 2008 08:49:24 +0300
    > > Muli Ben-Yehuda wrote:
    > >
    > > > On Tue, May 13, 2008 at 03:04:50PM +0900, FUJITA Tomonori wrote:

    >
    > > > Awesome! Much needed, thank you for doing this.

    > >
    > > No problem. Well, as you know, it's just a base. We need more work to
    > > solve the problems on the top of this.

    > Yes thank you!
    > >
    > > I'd like to have a mechanism to register a hook called when a new pci
    > > (or dma capable) device is created. It enables IOMMUs to set up an
    > > appropriate dma_mapping_ops per device. It could also enables us to
    > > simplify the IOMMUs code to initilize devices at startup (for exmple,
    > > intel-iommu checks all the pci devices and creates a domain per device
    > > if necessary).

    > I wanted to try and create a test version of this, at least for the
    > calgary side, but ran into an error with this patch set:
    >
    > Fusion MPT SAS Host driver 3.04.06
    > ACPI: PCI Interrupt 0000:34:00.0[A] -> GSI 142 (level, low) -> IRQ 142
    > mptbase: ioc0: Initiating bringup
    > ioc0: LSISAS1078 C1: Capabilities={Initiator}
    > mptbase: ioc0: PCI-MSI enabled
    > Calgary: DMA error on CalIOC2 PHB 0x33
    > Calgary: 0x02000000@CSR 0x00000000@PLSSR 0xb0008000@CSMR 0x00000000@MCK
    > Calgary: 0x00000000@0x810 0xfee0c000@0x820 0x00000000@0x830
    > 0x00000000@0x840 0x03804a00@0x850 0x00000000@0x860 0x00000000@0x870
    > Calgary: 0x00000000@0xcb0
    > mptbase: ioc0: Initiating recovery
    > mptbase: ioc0: WARNING - Unexpected doorbell active!
    > mptbase: ioc0: WARNING - NOT READY!
    > mptbase: ioc0: WARNING - Cannot recover rc = -1!
    > mptbase: ioc0: WARNING - Firmware Reload FAILED!
    > Clocksource tsc unstable (delta = 48333779773 ns)
    >
    > Not sure what is causing this error, but will keep digging. Any ideas?


    Hmm, you don't hit this without my patches, right?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [PATCH 0/2] x86: per-device dma_mapping_ops

    FUJITA Tomonori writes:

    > This patchset adds per-device dma_mapping_ops support for
    > CONFIG_X86_64 like POWER architecture does. This change enables us to
    > cleanly fix the Calgary IOMMU issue that some devices are not behind
    > the IOMMU [1]. It also would be helpful to handle KVM PCI passthrough.


    This makes it basically impossible to do stack ops, which some
    people have been doing.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [PATCH 0/2] x86: per-device dma_mapping_ops

    FUJITA Tomonori wrote:
    > On Thu, 15 May 2008 11:01:09 +0200
    > Andi Kleen wrote:
    >
    >> FUJITA Tomonori writes:
    >>
    >>> This patchset adds per-device dma_mapping_ops support for
    >>> CONFIG_X86_64 like POWER architecture does. This change enables us to
    >>> cleanly fix the Calgary IOMMU issue that some devices are not behind
    >>> the IOMMU [1]. It also would be helpful to handle KVM PCI passthrough.

    >> This makes it basically impossible to do stack ops, which some
    >> people have been doing.

    >
    > Seems that I misunderstand what those people want.
    >
    > What those people want to do and how the stack ops achieve it? Or can
    > you tell me where their patches are?


    I've seen it in two cases: first was for KVM IO bypass and the other was a
    (unfinished) patch to support the NoDMA bitmaps on some systems.

    In this case you really want to do a wrapper around the existing ops
    and extend the mapping.

    That worked fine by just replacing the global pointer, but will
    be quite hard in your set up.

    -Andi


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [PATCH 0/2] x86: per-device dma_mapping_ops

    On Thu, 15 May 2008 11:30:12 +0200
    Andi Kleen wrote:

    > FUJITA Tomonori wrote:
    > > On Thu, 15 May 2008 11:01:09 +0200
    > > Andi Kleen wrote:
    > >
    > >> FUJITA Tomonori writes:
    > >>
    > >>> This patchset adds per-device dma_mapping_ops support for
    > >>> CONFIG_X86_64 like POWER architecture does. This change enables us to
    > >>> cleanly fix the Calgary IOMMU issue that some devices are not behind
    > >>> the IOMMU [1]. It also would be helpful to handle KVM PCI passthrough.
    > >> This makes it basically impossible to do stack ops, which some
    > >> people have been doing.

    > >
    > > Seems that I misunderstand what those people want.
    > >
    > > What those people want to do and how the stack ops achieve it? Or can
    > > you tell me where their patches are?

    >
    > I've seen it in two cases: first was for KVM IO bypass and the other was a
    > (unfinished) patch to support the NoDMA bitmaps on some systems.
    >
    > In this case you really want to do a wrapper around the existing ops
    > and extend the mapping.
    >
    > That worked fine by just replacing the global pointer, but will
    > be quite hard in your set up.


    Thanks,

    I thought that KVM people want to do it per device (in the first
    case). So with my patchse, they can replace the dma_ops pointer in
    dev_archdata with what they want.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [PATCH 0/2] x86: per-device dma_mapping_ops

    On Thu, 15 May 2008 11:01:09 +0200
    Andi Kleen wrote:

    > FUJITA Tomonori writes:
    >
    > > This patchset adds per-device dma_mapping_ops support for
    > > CONFIG_X86_64 like POWER architecture does. This change enables us to
    > > cleanly fix the Calgary IOMMU issue that some devices are not behind
    > > the IOMMU [1]. It also would be helpful to handle KVM PCI passthrough.

    >
    > This makes it basically impossible to do stack ops, which some
    > people have been doing.


    Seems that I misunderstand what those people want.

    What those people want to do and how the stack ops achieve it? Or can
    you tell me where their patches are?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [PATCH 0/2] x86: per-device dma_mapping_ops


    > I thought that KVM people want to do it per device (in the first
    > case). So with my patchse, they can replace the dma_ops pointer in
    > dev_archdata with what they want.


    But where would they save the original pointer?

    -Andi

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [PATCH 0/2] x86: per-device dma_mapping_ops

    On Thu, 2008-05-15 at 18:16 +0900, FUJITA Tomonori wrote:
    > On Thu, 15 May 2008 11:01:09 +0200
    > Andi Kleen wrote:
    >
    > > FUJITA Tomonori writes:
    > >
    > > > This patchset adds per-device dma_mapping_ops support for
    > > > CONFIG_X86_64 like POWER architecture does. This change enables us to
    > > > cleanly fix the Calgary IOMMU issue that some devices are not behind
    > > > the IOMMU [1]. It also would be helpful to handle KVM PCI passthrough.

    > >
    > > This makes it basically impossible to do stack ops, which some
    > > people have been doing.

    >
    > Seems that I misunderstand what those people want.
    >
    > What those people want to do and how the stack ops achieve it? Or can
    > you tell me where their patches are?

    Yes an explanation of stack ops, or a pointer to a patch set that
    implements them would be very useful.


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: [PATCH 0/2] x86: per-device dma_mapping_ops

    On Thu, 2008-05-15 at 11:30 +0900, FUJITA Tomonori wrote:
    > On Wed, 14 May 2008 19:00:13 -0700
    > Alexis Bruemmer wrote:
    >
    > > On Thu, 2008-05-15 at 10:12 +0900, FUJITA Tomonori wrote:
    > > > On Wed, 14 May 2008 08:49:24 +0300
    > > > Muli Ben-Yehuda wrote:
    > > >
    > > > > On Tue, May 13, 2008 at 03:04:50PM +0900, FUJITA Tomonori wrote:

    > >
    > > > > Awesome! Much needed, thank you for doing this.
    > > >
    > > > No problem. Well, as you know, it's just a base. We need more work to
    > > > solve the problems on the top of this.

    > > Yes thank you!
    > > >
    > > > I'd like to have a mechanism to register a hook called when a new pci
    > > > (or dma capable) device is created. It enables IOMMUs to set up an
    > > > appropriate dma_mapping_ops per device. It could also enables us to
    > > > simplify the IOMMUs code to initilize devices at startup (for exmple,
    > > > intel-iommu checks all the pci devices and creates a domain per device
    > > > if necessary).

    > > I wanted to try and create a test version of this, at least for the
    > > calgary side, but ran into an error with this patch set:
    > >
    > > Fusion MPT SAS Host driver 3.04.06
    > > ACPI: PCI Interrupt 0000:34:00.0[A] -> GSI 142 (level, low) -> IRQ 142
    > > mptbase: ioc0: Initiating bringup
    > > ioc0: LSISAS1078 C1: Capabilities={Initiator}
    > > mptbase: ioc0: PCI-MSI enabled
    > > Calgary: DMA error on CalIOC2 PHB 0x33
    > > Calgary: 0x02000000@CSR 0x00000000@PLSSR 0xb0008000@CSMR 0x00000000@MCK
    > > Calgary: 0x00000000@0x810 0xfee0c000@0x820 0x00000000@0x830
    > > 0x00000000@0x840 0x03804a00@0x850 0x00000000@0x860 0x00000000@0x870
    > > Calgary: 0x00000000@0xcb0
    > > mptbase: ioc0: Initiating recovery
    > > mptbase: ioc0: WARNING - Unexpected doorbell active!
    > > mptbase: ioc0: WARNING - NOT READY!
    > > mptbase: ioc0: WARNING - Cannot recover rc = -1!
    > > mptbase: ioc0: WARNING - Firmware Reload FAILED!
    > > Clocksource tsc unstable (delta = 48333779773 ns)
    > >
    > > Not sure what is causing this error, but will keep digging. Any ideas?

    >
    > Hmm, you don't hit this without my patches, right?

    oops, you are right, this failure was due to a .config change not your
    patch set (MSI not behaving on MegaRAID). Sorry for the false alarm.
    Your patches work as expected.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: [PATCH 0/2] x86: per-device dma_mapping_ops

    On Thu, May 15, 2008 at 10:12:25AM +0900, FUJITA Tomonori wrote:
    > On Wed, 14 May 2008 08:49:24 +0300
    > Muli Ben-Yehuda wrote:
    >
    > > On Tue, May 13, 2008 at 03:04:50PM +0900, FUJITA Tomonori wrote:
    > >
    > > > This patchset adds per-device dma_mapping_ops support for
    > > > CONFIG_X86_64 like POWER architecture does. This change enables us
    > > > to cleanly fix the Calgary IOMMU issue that some devices are not
    > > > behind the IOMMU [1]. It also would be helpful to handle KVM PCI
    > > > passthrough.

    > >
    > > Awesome! Much needed, thank you for doing this.

    >
    > No problem. Well, as you know, it's just a base. We need more work
    > to solve the problems on the top of this.
    >
    > I'd like to have a mechanism to register a hook called when a new
    > pci (or dma capable) device is created. It enables IOMMUs to set up
    > an appropriate dma_mapping_ops per device.


    That's great---it will be needed to support hot-plugging of devices on
    systems with isolation-capable IOMMUs.

    > It could also enables us to simplify the IOMMUs code to initilize
    > devices at startup (for exmple, intel-iommu checks all the pci
    > devices and creates a domain per device if necessary).


    I'm not sure if it will be easier than the current "loop over all
    devices" method, but since we will need it for hotplug anyway, we
    might as well just switch to it.

    > I'll post an updated version against -mm. If people seems to be fine
    > with per-device dma_mapping_ops, then I'll work on further issues.


    Excellent.

    Cheers,
    Muli

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: [PATCH 0/2] x86: per-device dma_mapping_ops

    On Thu, May 15, 2008 at 06:41:26PM +0900, FUJITA Tomonori wrote:

    > I thought that KVM people want to do it per device (in the first
    > case). So with my patchse, they can replace the dma_ops pointer in
    > dev_archdata with what they want.


    That's my understanding too. We use stackable ops as a poor man's
    replacement for per-device ops (depending on what kind of device it
    is, call the original ops or our pvdma ops).

    Cheers,
    Muli



    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: [PATCH 0/2] x86: per-device dma_mapping_ops

    On Thu, May 15, 2008 at 12:48:04PM +0200, Andi Kleen wrote:
    >
    > > I thought that KVM people want to do it per device (in the first
    > > case). So with my patchse, they can replace the dma_ops pointer in
    > > dev_archdata with what they want.

    >
    > But where would they save the original pointer?


    See my other mail on this subject, we don't need the original pointer,
    we just use stackable ops as a poor man's replacement for per-device
    ops.

    Cheers,
    Muli
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: [PATCH 0/2] x86: per-device dma_mapping_ops

    On Wed, May 14, 2008 at 07:00:13PM -0700, Alexis Bruemmer wrote:

    > I wanted to try and create a test version of this, at least for the
    > calgary side, but ran into an error with this patch set:
    >
    > Fusion MPT SAS Host driver 3.04.06
    > ACPI: PCI Interrupt 0000:34:00.0[A] -> GSI 142 (level, low) -> IRQ 142
    > mptbase: ioc0: Initiating bringup
    > ioc0: LSISAS1078 C1: Capabilities={Initiator}
    > mptbase: ioc0: PCI-MSI enabled
    > Calgary: DMA error on CalIOC2 PHB 0x33
    > Calgary: 0x02000000@CSR 0x00000000@PLSSR 0xb0008000@CSMR 0x00000000@MCK
    > Calgary: 0x00000000@0x810 0xfee0c000@0x820 0x00000000@0x830
    > 0x00000000@0x840 0x03804a00@0x850 0x00000000@0x860 0x00000000@0x870
    > Calgary: 0x00000000@0xcb0


    Calgary caught an errant DMA. If it was working before, we are
    probably mis-programming the TCE tables. The first thing to check is
    whether all dma_map_xxx calls by mptbase end up calling the Calgary
    dma_ops.

    Cheers,
    Muli
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: [PATCH 2/2] x86: per-device dma_mapping_ops support

    On Mon, May 12, 2008 at 11:04 PM, FUJITA Tomonori
    wrote:
    > This adds per-device dma_mapping_ops support for CONFIG_X86_64.
    >
    > A pointer to dma_mapping_ops to struct dev_archdata is added. If the
    > pointer is non NULL, DMA operations in asm/dma-mapping.h use it. If
    > it's NULL, the system-wide dma_ops pointer is used as before.
    >
    > Signed-off-by: FUJITA Tomonori
    > ---
    > arch/x86/kernel/pci-calgary_64.c | 2 +-
    > arch/x86/kernel/pci-dma.c | 2 +-
    > arch/x86/kernel/pci-gart_64.c | 2 +-
    > arch/x86/kernel/pci-nommu.c | 14 +-----
    > arch/x86/kernel/pci-swiotlb_64.c | 2 +-
    > include/asm-x86/device.h | 3 +
    > include/asm-x86/dma-mapping.h | 95 ++++++++++++++++++++++++++------------
    > 7 files changed, 74 insertions(+), 46 deletions(-)
    >
    > diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kernel/pci-calgary_64.c
    > index e28ec49..dca9a82 100644
    > --- a/arch/x86/kernel/pci-calgary_64.c
    > +++ b/arch/x86/kernel/pci-calgary_64.c
    > @@ -541,7 +541,7 @@ error:
    > return ret;
    > }
    >
    > -static const struct dma_mapping_ops calgary_dma_ops = {
    > +static struct dma_mapping_ops calgary_dma_ops = {
    > .alloc_coherent = calgary_alloc_coherent,
    > .map_single = calgary_map_single,
    > .unmap_single = calgary_unmap_single,
    > diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
    > index 0c37f16..33ded93 100644
    > --- a/arch/x86/kernel/pci-dma.c
    > +++ b/arch/x86/kernel/pci-dma.c
    > @@ -11,7 +11,7 @@
    > int forbid_dac __read_mostly;
    > EXPORT_SYMBOL(forbid_dac);
    >
    > -const struct dma_mapping_ops *dma_ops;
    > +struct dma_mapping_ops *dma_ops;
    > EXPORT_SYMBOL(dma_ops);
    >
    > static int iommu_sac_force __read_mostly;
    > diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
    > index e1a6954..8469f76 100644
    > --- a/arch/x86/kernel/pci-gart_64.c
    > +++ b/arch/x86/kernel/pci-gart_64.c
    > @@ -621,7 +621,7 @@ static __init int init_k8_gatt(struct agp_kern_info *info)
    >
    > extern int agp_amd64_init(void);
    >
    > -static const struct dma_mapping_ops gart_dma_ops = {
    > +static struct dma_mapping_ops gart_dma_ops = {
    > .map_single = gart_map_single,
    > .map_simple = gart_map_simple,
    > .unmap_single = gart_unmap_single,
    > diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c
    > index 05d70b8..67cc5ee 100644
    > --- a/arch/x86/kernel/pci-nommu.c
    > +++ b/arch/x86/kernel/pci-nommu.c
    > @@ -72,21 +72,9 @@ static int nommu_map_sg(struct device *hwdev, struct scatterlist *sg,
    > return nents;
    > }
    >
    > -/* Make sure we keep the same behaviour */
    > -static int nommu_mapping_error(struct device *hwdev, dma_addr_t dma_addr)
    > -{
    > -#ifdef CONFIG_X86_32
    > - return 0;
    > -#else
    > - return (dma_addr == bad_dma_address);
    > -#endif
    > -}
    > -
    > -
    > -const struct dma_mapping_ops nommu_dma_ops = {
    > +struct dma_mapping_ops nommu_dma_ops = {
    > .map_single = nommu_map_single,
    > .map_sg = nommu_map_sg,
    > - .mapping_error = nommu_mapping_error,
    > .is_phys = 1,
    > };
    >
    > diff --git a/arch/x86/kernel/pci-swiotlb_64.c b/arch/x86/kernel/pci-swiotlb_64.c
    > index 490da7f..a464016 100644
    > --- a/arch/x86/kernel/pci-swiotlb_64.c
    > +++ b/arch/x86/kernel/pci-swiotlb_64.c
    > @@ -18,7 +18,7 @@ swiotlb_map_single_phys(struct device *hwdev, phys_addr_t paddr, size_t size,
    > return swiotlb_map_single(hwdev, phys_to_virt(paddr), size, direction);
    > }
    >
    > -const struct dma_mapping_ops swiotlb_dma_ops = {
    > +struct dma_mapping_ops swiotlb_dma_ops = {
    > .mapping_error = swiotlb_dma_mapping_error,
    > .alloc_coherent = swiotlb_alloc_coherent,
    > .free_coherent = swiotlb_free_coherent,
    > diff --git a/include/asm-x86/device.h b/include/asm-x86/device.h
    > index 87a7153..3c034f4 100644
    > --- a/include/asm-x86/device.h
    > +++ b/include/asm-x86/device.h
    > @@ -5,6 +5,9 @@ struct dev_archdata {
    > #ifdef CONFIG_ACPI
    > void *acpi_handle;
    > #endif
    > +#ifdef CONFIG_X86_64
    > +struct dma_mapping_ops *dma_ops;
    > +#endif
    > #ifdef CONFIG_DMAR
    > void *iommu; /* hook for IOMMU specific extension */
    > #endif


    do you have other patch to assign value to dma_ops for every device?
    it is always NULL at this time.

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 1 of 2 1 2 LastLast