[PATCH 0/3] some small GART cleanups - Kernel

This is a discussion on [PATCH 0/3] some small GART cleanups - Kernel ; Hi, this small patch series contains some cleanups for the K8 GART driver in the x86 architecture. diffstat: arch/x86/kernel/pci-gart_64.c | 38 ++++++++++++++++++-------------------- include/asm-x86/gart.h | 2 ++ 2 files changed, 20 insertions(+), 20 deletions(-) -- To unsubscribe from this list: send ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: [PATCH 0/3] some small GART cleanups

  1. [PATCH 0/3] some small GART cleanups

    Hi,

    this small patch series contains some cleanups for the K8 GART driver in
    the x86 architecture.

    diffstat:

    arch/x86/kernel/pci-gart_64.c | 38 ++++++++++++++++++--------------------
    include/asm-x86/gart.h | 2 ++
    2 files changed, 20 insertions(+), 20 deletions(-)



    --
    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 3/3] x86/iommu: use __GFP_ZERO instead of memset for GART


    * Joerg Roedel wrote:

    > #ifdef CONFIG_IOMMU_LEAK
    > if (leak_trace) {
    > - iommu_leak_tab = (void *)__get_free_pages(GFP_KERNEL,
    > + iommu_leak_tab = (void *)__get_free_pages(GFP_KERNEL|__GFP_ZERO,
    > get_order(iommu_pages*sizeof(void *)));
    > - if (iommu_leak_tab)
    > - memset(iommu_leak_tab, 0, iommu_pages * 8);
    > else
    > printk(KERN_DEBUG
    > "PCI-DMA: Cannot allocate leak trace area\n");


    hm, that looks broken.

    Ingo
    --
    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 3/3] x86/iommu: use __GFP_ZERO instead of memset for GART

    On Thu, Sep 25, 2008 at 12:20:12PM +0200, Ingo Molnar wrote:
    >
    > * Joerg Roedel wrote:
    >
    > > #ifdef CONFIG_IOMMU_LEAK
    > > if (leak_trace) {
    > > - iommu_leak_tab = (void *)__get_free_pages(GFP_KERNEL,
    > > + iommu_leak_tab = (void *)__get_free_pages(GFP_KERNEL|__GFP_ZERO,
    > > get_order(iommu_pages*sizeof(void *)));
    > > - if (iommu_leak_tab)
    > > - memset(iommu_leak_tab, 0, iommu_pages * 8);
    > > else
    > > printk(KERN_DEBUG
    > > "PCI-DMA: Cannot allocate leak trace area\n");

    >
    > hm, that looks broken.


    Argh, yes. Please try this one:

    =
    From c402fd7f5fe930d45a02ef863bf3fb61851e6ad0 Mon Sep 17 00:00:00 2001
    From: Joerg Roedel
    Date: Thu, 25 Sep 2008 12:39:06 +0200
    Subject: [PATCH] x86/iommu: use __GFP_ZERO instead of memset for GART

    Signed-off-by: Joerg Roedel
    ---
    arch/x86/kernel/pci-gart_64.c | 13 +++++--------
    1 files changed, 5 insertions(+), 8 deletions(-)

    diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
    index aecea06..d077116 100644
    --- a/arch/x86/kernel/pci-gart_64.c
    +++ b/arch/x86/kernel/pci-gart_64.c
    @@ -674,13 +674,13 @@ static __init int init_k8_gatt(struct agp_kern_info *info)
    info->aper_size = aper_size >> 20;

    gatt_size = (aper_size >> PAGE_SHIFT) * sizeof(u32);
    - gatt = (void *)__get_free_pages(GFP_KERNEL, get_order(gatt_size));
    + gatt = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
    + get_order(gatt_size));
    if (!gatt)
    panic("Cannot allocate GATT table");
    if (set_memory_uc((unsigned long)gatt, gatt_size >> PAGE_SHIFT))
    panic("Could not set GART PTEs to uncacheable pages");

    - memset(gatt, 0, gatt_size);
    agp_gatt_table = gatt;

    enable_gart_translations();
    @@ -788,19 +788,16 @@ void __init gart_iommu_init(void)
    iommu_size = check_iommu_size(info.aper_base, aper_size);
    iommu_pages = iommu_size >> PAGE_SHIFT;

    - iommu_gart_bitmap = (void *) __get_free_pages(GFP_KERNEL,
    + iommu_gart_bitmap = (void *) __get_free_pages(GFP_KERNEL | __GFP_ZERO,
    get_order(iommu_pages/8));
    if (!iommu_gart_bitmap)
    panic("Cannot allocate iommu bitmap\n");
    - memset(iommu_gart_bitmap, 0, iommu_pages/8);

    #ifdef CONFIG_IOMMU_LEAK
    if (leak_trace) {
    - iommu_leak_tab = (void *)__get_free_pages(GFP_KERNEL,
    + iommu_leak_tab = (void *)__get_free_pages(GFP_KERNEL|__GFP_ZERO,
    get_order(iommu_pages*sizeof(void *)));
    - if (iommu_leak_tab)
    - memset(iommu_leak_tab, 0, iommu_pages * 8);
    - else
    + if (!iommu_leak_tab)
    printk(KERN_DEBUG
    "PCI-DMA: Cannot allocate leak trace area\n");
    }
    --
    1.5.6.4


    --
    | AMD Saxony Limited Liability Company & Co. KG
    Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
    System | Register Court Dresden: HRA 4896
    Research | General Partner authorized to represent:
    Center | AMD Saxony LLC (Wilmington, Delaware, US)
    | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy

    --
    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 3/3] x86/iommu: use __GFP_ZERO instead of memset for GART


    another thing:

    How hard would it be to add an CONFIG_IOMMU_DEBUG option that forces as
    many DMA requests to go via the IOMMU as possible?

    This slows things down of course so it's only for debugging - but it
    also makes sure that we utilize the IOMMU code to the maximum - which is
    not normally the case.

    Would be nice to have it .config driven (default-disabled), so that
    -tip's randconfig testing can stumble upon it every now and then. I've
    got GART test-systems - this way we could find certain types of IOMMU
    breakages sooner.

    Ingo
    --
    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 3/3] x86/iommu: use __GFP_ZERO instead of memset for GART


    * Joerg Roedel wrote:

    > > > - if (iommu_leak_tab)
    > > > - memset(iommu_leak_tab, 0, iommu_pages * 8);
    > > > else
    > > > printk(KERN_DEBUG
    > > > "PCI-DMA: Cannot allocate leak trace area\n");

    > >
    > > hm, that looks broken.

    >
    > Argh, yes. Please try this one:


    applied these patches to tip/x86/iommu:

    0114267: x86/iommu: use __GFP_ZERO instead of memset for GART
    3610f21: x86/iommu: convert GART need_flush to bool
    237a622: x86/iommu: make GART driver checkpatch clean

    thanks Joerg!

    Fujita, do they look fine to you too?

    Ingo
    --
    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 3/3] x86/iommu: use __GFP_ZERO instead of memset for GART

    On Sat, 27 Sep 2008 20:14:38 +0200
    Ingo Molnar wrote:

    >
    > * Joerg Roedel wrote:
    >
    > > > > - if (iommu_leak_tab)
    > > > > - memset(iommu_leak_tab, 0, iommu_pages * 8);
    > > > > else
    > > > > printk(KERN_DEBUG
    > > > > "PCI-DMA: Cannot allocate leak trace area\n");
    > > >
    > > > hm, that looks broken.

    > >
    > > Argh, yes. Please try this one:

    >
    > applied these patches to tip/x86/iommu:
    >
    > 0114267: x86/iommu: use __GFP_ZERO instead of memset for GART
    > 3610f21: x86/iommu: convert GART need_flush to bool
    > 237a622: x86/iommu: make GART driver checkpatch clean
    >
    > thanks Joerg!
    >
    > Fujita, do they look fine to you too?


    Yeah, all the patches look trivial and fine.

    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/

  7. Re: [PATCH 3/3] x86/iommu: use __GFP_ZERO instead of memset for GART

    On Sat, 27 Sep 2008 20:18:55 +0200
    Ingo Molnar wrote:

    > another thing:
    >
    > How hard would it be to add an CONFIG_IOMMU_DEBUG option that forces as
    > many DMA requests to go via the IOMMU as possible?
    >
    > This slows things down of course so it's only for debugging - but it
    > also makes sure that we utilize the IOMMU code to the maximum - which is
    > not normally the case.


    If you use iommu=force boot option, GART always tries to use the
    IOMMU.
    --
    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 3/3] x86/iommu: use __GFP_ZERO instead of memset for GART

    On Sat, Sep 27, 2008 at 08:18:55PM +0200, Ingo Molnar wrote:
    >
    > another thing:
    >
    > How hard would it be to add an CONFIG_IOMMU_DEBUG option that forces as
    > many DMA requests to go via the IOMMU as possible?
    >
    > This slows things down of course so it's only for debugging - but it
    > also makes sure that we utilize the IOMMU code to the maximum - which is
    > not normally the case.
    >
    > Would be nice to have it .config driven (default-disabled), so that
    > -tip's randconfig testing can stumble upon it every now and then. I've
    > got GART test-systems - this way we could find certain types of IOMMU
    > breakages sooner.


    For AMD IOMMU I disabled the round-robin allocator to stress-test the
    code. This means that the address allocation bitmap is always traversed
    from the first bit. In consequence the TLB flushing is stressed a lot
    (both in hardware and software) because the same DMA addresses are used
    again and again. For testing I hardcoded it into the driver but I can
    also make it depend on CONFIG_IOMMU_DEBUG.

    Joerg

    --
    | AMD Saxony Limited Liability Company & Co. KG
    Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
    System | Register Court Dresden: HRA 4896
    Research | General Partner authorized to represent:
    Center | AMD Saxony LLC (Wilmington, Delaware, US)
    | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy

    --
    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 3/3] x86/iommu: use __GFP_ZERO instead of memset for GART


    * Joerg Roedel wrote:

    > On Sat, Sep 27, 2008 at 08:18:55PM +0200, Ingo Molnar wrote:
    > >
    > > another thing:
    > >
    > > How hard would it be to add an CONFIG_IOMMU_DEBUG option that forces as
    > > many DMA requests to go via the IOMMU as possible?
    > >
    > > This slows things down of course so it's only for debugging - but it
    > > also makes sure that we utilize the IOMMU code to the maximum - which is
    > > not normally the case.
    > >
    > > Would be nice to have it .config driven (default-disabled), so that
    > > -tip's randconfig testing can stumble upon it every now and then. I've
    > > got GART test-systems - this way we could find certain types of IOMMU
    > > breakages sooner.

    >
    > For AMD IOMMU I disabled the round-robin allocator to stress-test the
    > code. This means that the address allocation bitmap is always
    > traversed from the first bit. In consequence the TLB flushing is
    > stressed a lot (both in hardware and software) because the same DMA
    > addresses are used again and again. For testing I hardcoded it into
    > the driver but I can also make it depend on CONFIG_IOMMU_DEBUG.


    yes - could you please make a new option for it,
    CONFIG_IOMMU_DEBUG_FORCE=y or so - and cover all iommus that support it?

    Ingo
    --
    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 3/3] x86/iommu: use __GFP_ZERO instead of memset for GART

    On Mon, 29 Sep 2008 10:56:47 +0200
    Ingo Molnar wrote:

    >
    > * Joerg Roedel wrote:
    >
    > > On Sat, Sep 27, 2008 at 08:18:55PM +0200, Ingo Molnar wrote:
    > > >
    > > > another thing:
    > > >
    > > > How hard would it be to add an CONFIG_IOMMU_DEBUG option that forces as
    > > > many DMA requests to go via the IOMMU as possible?
    > > >
    > > > This slows things down of course so it's only for debugging - but it
    > > > also makes sure that we utilize the IOMMU code to the maximum - which is
    > > > not normally the case.
    > > >
    > > > Would be nice to have it .config driven (default-disabled), so that
    > > > -tip's randconfig testing can stumble upon it every now and then. I've
    > > > got GART test-systems - this way we could find certain types of IOMMU
    > > > breakages sooner.

    > >
    > > For AMD IOMMU I disabled the round-robin allocator to stress-test the
    > > code. This means that the address allocation bitmap is always
    > > traversed from the first bit. In consequence the TLB flushing is
    > > stressed a lot (both in hardware and software) because the same DMA
    > > addresses are used again and again. For testing I hardcoded it into
    > > the driver but I can also make it depend on CONFIG_IOMMU_DEBUG.

    >
    > yes - could you please make a new option for it,
    > CONFIG_IOMMU_DEBUG_FORCE=y or so - and cover all iommus that support it?


    I'm not sure we are talking about the same thing. Surely, I and Joerg
    are talking different things.

    GART driver doesn't need to use the IOMMU hardware at all times. GART
    does a virtual mapping only when necessary (a device needs to handle
    an address that it can't access to). But as I wrote, if you use
    iommu=force, GART driver always use the IOMMU hardware.


    Other x86 IOMMU drivers always use the IOMMU hardware. Except for
    Intel VT-D, they manage free virtual I/O space in the round-robin
    manner with the bitmap algorithm to avoid frequent IOTLB flush. Joerg
    said he tested AMD IOMMU driver with the round-robin manner disabled
    so AMD IOMMU driver uses the same virtual I/O space with lots of IOTLB
    flush.
    --
    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 3/3] x86/iommu: use __GFP_ZERO instead of memset for GART


    * FUJITA Tomonori wrote:

    > > yes - could you please make a new option for it,
    > > CONFIG_IOMMU_DEBUG_FORCE=y or so - and cover all iommus that support
    > > it?

    >
    > I'm not sure we are talking about the same thing. Surely, I and Joerg
    > are talking different things.
    >
    > GART driver doesn't need to use the IOMMU hardware at all times. GART
    > does a virtual mapping only when necessary (a device needs to handle
    > an address that it can't access to). But as I wrote, if you use
    > iommu=force, GART driver always use the IOMMU hardware.


    yes - but iommu=force is not randconfig covered, hence it never gets
    tested by -tip testing. So my suggestion was a really simple patch: a
    new Kconfig entry that makes iommu=force default.

    CONFIG_BOOTPARAM_IOMMU_FORCE=y would be the right name for it. (disabled
    by default, of course)

    > Other x86 IOMMU drivers always use the IOMMU hardware. Except for
    > Intel VT-D, they manage free virtual I/O space in the round-robin
    > manner with the bitmap algorithm to avoid frequent IOTLB flush. Joerg
    > said he tested AMD IOMMU driver with the round-robin manner disabled
    > so AMD IOMMU driver uses the same virtual I/O space with lots of IOTLB
    > flush.


    all i'm suggesting is to please expose existing debug capabilities in
    the .config space, so that it can be tested in automated setups.

    Ingo
    --
    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 3/3] x86/iommu: use __GFP_ZERO instead of memset for GART

    Ingo Molnar wrote:
    >
    > all i'm suggesting is to please expose existing debug capabilities in
    > the .config space, so that it can be tested in automated setups.
    >


    Boot configurations, too, can be tested in automated setups, and there
    is benefit to being able to do that without compilation. However, what
    we'd need is a machine-readable description that one can select a
    configuration from.

    -hpa
    --
    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