[ANNOUNCE] iommu-2.6.git tree - Kernel

This is a discussion on [ANNOUNCE] iommu-2.6.git tree - Kernel ; As previously threatened, I've created an iommu-2.6.git tree: git://git.infradead.org/iommu-2.6.git http://git.infradead.org/iommu-2.6.git I've rounded up the patches which have been pending for a while and which would have been in linux-next if Stephen hadn't been away, and I'm planning to ask Linus ...

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

Thread: [ANNOUNCE] iommu-2.6.git tree

  1. [ANNOUNCE] iommu-2.6.git tree

    As previously threatened, I've created an iommu-2.6.git tree:
    git://git.infradead.org/iommu-2.6.git
    http://git.infradead.org/iommu-2.6.git

    I've rounded up the patches which have been pending for a while and
    which would have been in linux-next if Stephen hadn't been away, and I'm
    planning to ask Linus to pull it early next week, before the merge
    window closes.

    If there's anything missing which should be in 2.6.28, now is the time
    to shout. I don't want anything new and exciting yet though please; only
    patches which have already been posted and reviewed, or necessary fixes.

    Stephen, please could you add this tree to linux-next?

    Current contents:

    Andreas Herrmann (1):
    amd_iommu: fix nasty bug that caused ILLEGAL_DEVICE_TABLE_ENTRY errors

    Cihula, Joseph (1):
    intel-iommu: disable Protected Memory Regions when DMA remapping enabled

    David Woodhouse (2):
    dmar: fix uninitialised 'ret' variable in dmar_parse_dev()
    Admit to maintaining VT-d, for my sins.

    FUJITA Tomonori (1):
    intel-iommu: use coherent_dma_mask in alloc_coherent

    Fenghua Yu (1):
    intel-iommu: IA64 support

    Suresh Siddha (1):
    dmar: use spin_lock_irqsave() in qi_submit_sync()

    Youquan Song (3):
    dmar: context cache and IOTLB invalidation using queued invalidation
    dmar: Use queued invalidation interface for IOTLB and context invalidation
    dmar: remove the quirk which disables dma-remapping when intr-remapping enabled


    --
    David Woodhouse Open Source Technology Centre
    David.Woodhouse@intel.com Intel Corporation

    --
    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: [ANNOUNCE] iommu-2.6.git tree

    Hi David,

    On Sat, 18 Oct 2008 16:30:43 +0100 David Woodhouse wrote:
    >
    > As previously threatened, I've created an iommu-2.6.git tree:
    > git://git.infradead.org/iommu-2.6.git
    > http://git.infradead.org/iommu-2.6.git
    >
    > Stephen, please could you add this tree to linux-next?


    Sure (I assume the "master" branch). However, I already have a tree in
    -next called iommu. It is one of the tip auto branches (auto-iommu-next)
    and is currently empty. So do I name this one dwmw2-iommu, or has Ingo
    finished with the other one?

    --
    Cheers,
    Stephen Rothwell sfr@canb.auug.org.au
    http://www.canb.auug.org.au/~sfr/

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkj6BCAACgkQjjKRsyhoI8w4PgCgite0v30eZH Pi6/xg+4DJdwbn
    BrwAmwX2M8pFsUOYDr71oFW4rUTfyING
    =dpwQ
    -----END PGP SIGNATURE-----


  3. Re: [ANNOUNCE] iommu-2.6.git tree

    On Sun, 2008-10-19 at 02:43 +1100, Stephen Rothwell wrote:
    > Sure (I assume the "master" branch).


    Yes. I don't use branches in public-facing repositories -- it's much
    better just to have separate trees.

    > However, I already have a tree in -next called iommu. It is one of the
    > tip auto branches (auto-iommu-next) and is currently empty. So do I name
    > this one dwmw2-iommu, or has Ingo finished with the other one?


    I believe the plan is that Ingo has finished with the other one and we
    use the new one instead, yes.

    --
    David Woodhouse Open Source Technology Centre
    David.Woodhouse@intel.com Intel Corporation

    --
    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: [ANNOUNCE] iommu-2.6.git tree

    On Sat, Oct 18, 2008 at 04:30:43PM +0100, David Woodhouse wrote:
    > As previously threatened, I've created an iommu-2.6.git tree:
    > git://git.infradead.org/iommu-2.6.git
    > http://git.infradead.org/iommu-2.6.git


    Is there a specific reason why IOMMU stuff should go to Linus without
    testing them in the x86 tree before? The DMA layer and IOMMU drivers are
    an integral component of the architecture and patches for it are best
    placed in the architecture tree instead of a seperate one, imho.

    Joerg

    --
    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: [ANNOUNCE] iommu-2.6.git tree

    On Sun, 2008-10-19 at 13:12 +0200, Joerg Roedel wrote:
    > On Sat, Oct 18, 2008 at 04:30:43PM +0100, David Woodhouse wrote:
    > > As previously threatened, I've created an iommu-2.6.git tree:
    > > git://git.infradead.org/iommu-2.6.git
    > > http://git.infradead.org/iommu-2.6.git

    >
    > Is there a specific reason why IOMMU stuff should go to Linus without
    > testing them in the x86 tree before? The DMA layer and IOMMU drivers are
    > an integral component of the architecture and patches for it are best
    > placed in the architecture tree instead of a seperate one, imho.


    This is the purpose that linux-next serves, not the x86 forest-of-doom.

    And I thought Ingo said his old iommu tree wasn't in there anyway? He
    said it was somewhere else, although I haven't actually managed to
    _find_ it.

    The Intel IOMMU appears on IA64 too, and doesn't want to be developed
    and tested off in an x86-specific corner by itself. And I'm going to be
    looking at other generic things we can do to improve IOMMU-related
    performance, which will touch on other architectures too.

    --
    David Woodhouse Open Source Technology Centre
    David.Woodhouse@intel.com Intel Corporation

    --
    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: [ANNOUNCE] iommu-2.6.git tree


    * David Woodhouse wrote:

    > On Sun, 2008-10-19 at 13:12 +0200, Joerg Roedel wrote:
    > > On Sat, Oct 18, 2008 at 04:30:43PM +0100, David Woodhouse wrote:
    > > > As previously threatened, I've created an iommu-2.6.git tree:
    > > > git://git.infradead.org/iommu-2.6.git
    > > > http://git.infradead.org/iommu-2.6.git

    > >
    > > Is there a specific reason why IOMMU stuff should go to Linus
    > > without testing them in the x86 tree before? The DMA layer and IOMMU
    > > drivers are an integral component of the architecture and patches
    > > for it are best placed in the architecture tree instead of a
    > > seperate one, imho.

    >
    > This is the purpose that linux-next serves, not the x86
    > forest-of-doom.
    >
    > And I thought Ingo said his old iommu tree wasn't in there anyway?
    > [...]


    That's weird, where did you get the impression from that i "dropped" the
    "old" IOMMU tree? It's alive and kicking, all the new IOMMU code that we
    queued up and tested in the last cycle for v2.6.28 have just gone
    upstream - about 80 commits.

    Please do not just jump into other people's workflow like that ... at
    minimum ask them what they'd prefer to do.

    Firstly, it's not at all clear to me what your role in this whole matter
    is, because you've not talked to us about it. Does your interest in this
    whole topic come from the fact that you recently got hired by Intel and
    got assigned to maintain Intel's IOMMU bits two months ago?

    The thing is, i havent seen a single IOMMU contribution from you in the
    last cycles, so it's weird that you now suddenly attempt to zap other
    people's trees from linux-next out of the blue ... without their
    knowledge and consent.

    Your help is welcome, and as i said it before i'd encourage you to run
    your tree - and if Linus wants to pull from you directly that's his and
    Andrew's call.

    At the moment IOMMU topics are a rather healthy machinery that clearly
    got new blood and new life in the past two kernel cycles. If you want to
    help out with this stuff then please start by contributing and working
    with people, not by trying to control 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/

  7. Re: [ANNOUNCE] iommu-2.6.git tree

    On Sun, 2008-10-19 at 14:47 +0200, Ingo Molnar wrote:
    > * David Woodhouse wrote:
    >
    > > On Sun, 2008-10-19 at 13:12 +0200, Joerg Roedel wrote:
    > > > On Sat, Oct 18, 2008 at 04:30:43PM +0100, David Woodhouse wrote:
    > > > > As previously threatened, I've created an iommu-2.6.git tree:
    > > > > git://git.infradead.org/iommu-2.6.git
    > > > > http://git.infradead.org/iommu-2.6.git
    > > >
    > > > Is there a specific reason why IOMMU stuff should go to Linus
    > > > without testing them in the x86 tree before? The DMA layer and IOMMU
    > > > drivers are an integral component of the architecture and patches
    > > > for it are best placed in the architecture tree instead of a
    > > > seperate one, imho.

    > >
    > > This is the purpose that linux-next serves, not the x86
    > > forest-of-doom.
    > >
    > > And I thought Ingo said his old iommu tree wasn't in there anyway?
    > > [...]

    >
    > That's weird, where did you get the impression from that i "dropped" the
    > "old" IOMMU tree? It's alive and kicking, all the new IOMMU code that we
    > queued up and tested in the last cycle for v2.6.28 have just gone
    > upstream - about 80 commits.


    I cannot find the tree which allegedly already exists -- and unless I'm
    mistaken, a number of patches seem to have fallen through the cracks in
    the last few weeks. Since I've been asked to start looking after the
    Intel IOMMU parts, it seemed sensible to make a git tree and round up
    those patches.

    I thought you and Thomas were working together, and I spoke to Thomas
    about it during the Kernel Summit. Unless I'm very much mistaken, he
    agreed that it makes sense to have a separate, real, git tree for
    cross-platform IOMMU-related work.

    If you want to pull that tree into yours, that's fine by me -- as long
    as it gets into linux-next.

    --
    David Woodhouse Open Source Technology Centre
    David.Woodhouse@intel.com Intel Corporation

    --
    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: [ANNOUNCE] iommu-2.6.git tree


    * David Woodhouse wrote:

    > On Sun, 2008-10-19 at 14:47 +0200, Ingo Molnar wrote:
    > > * David Woodhouse wrote:
    > >
    > > > On Sun, 2008-10-19 at 13:12 +0200, Joerg Roedel wrote:
    > > > > On Sat, Oct 18, 2008 at 04:30:43PM +0100, David Woodhouse wrote:
    > > > > > As previously threatened, I've created an iommu-2.6.git tree:
    > > > > > git://git.infradead.org/iommu-2.6.git
    > > > > > http://git.infradead.org/iommu-2.6.git
    > > > >
    > > > > Is there a specific reason why IOMMU stuff should go to Linus
    > > > > without testing them in the x86 tree before? The DMA layer and IOMMU
    > > > > drivers are an integral component of the architecture and patches
    > > > > for it are best placed in the architecture tree instead of a
    > > > > seperate one, imho.
    > > >
    > > > This is the purpose that linux-next serves, not the x86
    > > > forest-of-doom.
    > > >
    > > > And I thought Ingo said his old iommu tree wasn't in there anyway?
    > > > [...]

    > >
    > > That's weird, where did you get the impression from that i "dropped" the
    > > "old" IOMMU tree? It's alive and kicking, all the new IOMMU code that we
    > > queued up and tested in the last cycle for v2.6.28 have just gone
    > > upstream - about 80 commits.

    >
    > I cannot find the tree which allegedly already exists [...]


    it's tip/auto-iommu-next. "Empty" right now because it just got merged
    upstream last week.

    > [...] -- and unless I'm mistaken, a number of patches seem to have
    > fallen through the cracks in the last few weeks. Since I've been asked
    > to start looking after the Intel IOMMU parts, it seemed sensible to
    > make a git tree and round up those patches.


    hm, no patches have been lost that i'm aware of - the last ~10 days of
    inbox is not queued up yet because of the merge window - but those
    (except for urgent fixes) are v2.6.29 items anyway.

    > I thought you and Thomas were working together, and I spoke to Thomas
    > about it during the Kernel Summit. Unless I'm very much mistaken, he
    > agreed that it makes sense to have a separate, real, git tree for
    > cross-platform IOMMU-related work.
    >
    > If you want to pull that tree into yours, that's fine by me -- as long
    > as it gets into linux-next.


    okay, we can certainly do that. And if/when all future activities center
    around your tree, and there's no interaction with x86 platform bits, it
    will be natural for you to just not go over any middlemen.

    But i'd prefer to at least have some transitionary period - IOMMU
    changes are not easy topics and they caused subtle breakages a couple of
    times and it was quite handy that those breakages were generally seen by
    all x86 developers (and immediately fixed afterwards). 99% of the
    current iommu development activities are in the x86 space, so there's
    quite some alignment there.

    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/

  9. Re: [ANNOUNCE] iommu-2.6.git tree

    On Sun, 2008-10-19 at 19:26 +0200, Ingo Molnar wrote:
    > * David Woodhouse wrote:
    >
    > > On Sun, 2008-10-19 at 14:47 +0200, Ingo Molnar wrote:
    > > > * David Woodhouse wrote:
    > > >
    > > > > On Sun, 2008-10-19 at 13:12 +0200, Joerg Roedel wrote:
    > > > > > On Sat, Oct 18, 2008 at 04:30:43PM +0100, David Woodhouse wrote:
    > > > > > > As previously threatened, I've created an iommu-2.6.git tree:
    > > > > > > git://git.infradead.org/iommu-2.6.git
    > > > > > > http://git.infradead.org/iommu-2.6.git
    > > > > >
    > > > > > Is there a specific reason why IOMMU stuff should go to Linus
    > > > > > without testing them in the x86 tree before? The DMA layer and IOMMU
    > > > > > drivers are an integral component of the architecture and patches
    > > > > > for it are best placed in the architecture tree instead of a
    > > > > > seperate one, imho.
    > > > >
    > > > > This is the purpose that linux-next serves, not the x86
    > > > > forest-of-doom.
    > > > >
    > > > > And I thought Ingo said his old iommu tree wasn't in there anyway?
    > > > > [...]
    > > >
    > > > That's weird, where did you get the impression from that i "dropped" the
    > > > "old" IOMMU tree? It's alive and kicking, all the new IOMMU code that we
    > > > queued up and tested in the last cycle for v2.6.28 have just gone
    > > > upstream - about 80 commits.

    > >
    > > I cannot find the tree which allegedly already exists [...]

    >
    > it's tip/auto-iommu-next.


    I have no idea what that means.

    I tried 'locate auto-iommu-next' on master.kernel.org, but that doesn't
    seem to find anything -- is it elsewhere?

    Can you give a proper URL for a git tree, with a description explaining
    its nature, and everything that one would normally expect from a git
    tree?

    > > [...] -- and unless I'm mistaken, a number of patches seem to have
    > > fallen through the cracks in the last few weeks. Since I've been asked
    > > to start looking after the Intel IOMMU parts, it seemed sensible to
    > > make a git tree and round up those patches.

    >
    > hm, no patches have been lost that i'm aware of - the last ~10 days of
    > inbox is not queued up yet because of the merge window - but those
    > (except for urgent fixes) are v2.6.29 items anyway.


    There were patches outstanding which depended on both the interrupt
    remapping and the KVM work. And which add IA64 support for VT-d.

    > > I thought you and Thomas were working together, and I spoke to Thomas
    > > about it during the Kernel Summit. Unless I'm very much mistaken, he
    > > agreed that it makes sense to have a separate, real, git tree for
    > > cross-platform IOMMU-related work.
    > >
    > > If you want to pull that tree into yours, that's fine by me -- as long
    > > as it gets into linux-next.

    >
    > okay, we can certainly do that. And if/when all future activities center
    > around your tree, and there's no interaction with x86 platform bits, it
    > will be natural for you to just not go over any middlemen.
    >
    > But i'd prefer to at least have some transitionary period - IOMMU
    > changes are not easy topics and they caused subtle breakages a couple of
    > times and it was quite handy that those breakages were generally seen by
    > all x86 developers (and immediately fixed afterwards). 99% of the
    > current iommu development activities are in the x86 space, so there's
    > quite some alignment there.


    Again, isn't this what linux-next is for? But if you want to pull it
    into your own linux-next-but-only-for-x86 tree, then that's fine too; as
    I said.

    --
    David Woodhouse Open Source Technology Centre
    David.Woodhouse@intel.com Intel Corporation

    --
    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: [ANNOUNCE] iommu-2.6.git tree

    On Sun, Oct 19, 2008 at 12:19:58PM +0100, David Woodhouse wrote:
    > On Sun, 2008-10-19 at 13:12 +0200, Joerg Roedel wrote:
    > > On Sat, Oct 18, 2008 at 04:30:43PM +0100, David Woodhouse wrote:
    > > > As previously threatened, I've created an iommu-2.6.git tree:
    > > > git://git.infradead.org/iommu-2.6.git
    > > > http://git.infradead.org/iommu-2.6.git

    > >
    > > Is there a specific reason why IOMMU stuff should go to Linus without
    > > testing them in the x86 tree before? The DMA layer and IOMMU drivers are
    > > an integral component of the architecture and patches for it are best
    > > placed in the architecture tree instead of a seperate one, imho.

    >
    > This is the purpose that linux-next serves, not the x86 forest-of-doom.
    >
    > And I thought Ingo said his old iommu tree wasn't in there anyway? He
    > said it was somewhere else, although I haven't actually managed to
    > _find_ it.


    Its quite easy to learn the workflow of the x86 maintainers with the
    -tip tree. Just ask them, they are very responsive and friendly. I
    personally like that workflow with lots of topic branches. It gives a
    clear history of development.

    > The Intel IOMMU appears on IA64 too, and doesn't want to be developed
    > and tested off in an x86-specific corner by itself.


    This is a reason for a seperate Intel IOMMU tree which is pulled by
    Linus. But I don't think that this is a reason to take over control of
    all IOMMU development.

    > And I'm going to be looking at other generic things we can do to
    > improve IOMMU-related performance, which will touch on other
    > architectures too.


    As IOMMU infrastructure is architecture-local in Linux (except the
    very high level interface -> DMA-API) there is not much room for
    optimization which will touch multiple architectures. If Intel IOMMU is
    available on x86 and ia64 its definitly different for that driver. This
    is another reason for a seperate Intel IOMMU tree.

    Joerg

    --
    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: [ANNOUNCE] iommu-2.6.git tree

    On Sun, Oct 19, 2008 at 06:42:44PM +0100, David Woodhouse wrote:
    > On Sun, 2008-10-19 at 19:26 +0200, Ingo Molnar wrote:


    > > it's tip/auto-iommu-next.

    >
    > I have no idea what that means.
    >
    > I tried 'locate auto-iommu-next' on master.kernel.org, but that doesn't
    > seem to find anything -- is it elsewhere?


    It means the branch 'auto-iommu-next' in the -tip tree.

    > > hm, no patches have been lost that i'm aware of - the last ~10 days of
    > > inbox is not queued up yet because of the merge window - but those
    > > (except for urgent fixes) are v2.6.29 items anyway.

    >
    > There were patches outstanding which depended on both the interrupt
    > remapping and the KVM work. And which add IA64 support for VT-d.


    The x86 maintainers are not responsible for IA64 patches AFAIK. The KVM
    work will be merged by Avi.

    Joerg
    --
    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: [ANNOUNCE] iommu-2.6.git tree

    On Sun, 2008-10-19 at 18:42 +0100, David Woodhouse wrote:

    > > it's tip/auto-iommu-next.

    >
    > I have no idea what that means.


    git remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
    git remote update
    git checkout tip/auto-iommu-next



    --
    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: [ANNOUNCE] iommu-2.6.git tree

    On Sun, Oct 19, 2008 at 02:21:14PM +0100, David Woodhouse wrote:
    > I thought you and Thomas were working together, and I spoke to Thomas
    > about it during the Kernel Summit. Unless I'm very much mistaken, he
    > agreed that it makes sense to have a separate, real, git tree for
    > cross-platform IOMMU-related work.


    Is there any cross-platform IOMMU-related work outside the Intel IOMMU
    development?

    Joerg

    --
    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: [ANNOUNCE] iommu-2.6.git tree

    On Sun, 19 Oct 2008 12:19:58 +0100
    David Woodhouse wrote:

    > The Intel IOMMU appears on IA64 too, and doesn't want to be developed
    > and tested off in an x86-specific corner by itself. And I'm going to be
    > looking at other generic things we can do to improve IOMMU-related
    > performance, which will touch on other architectures too.


    Any plan to replace the current rb tree algorithm that VT-d
    IOMMU implementation uses with the bitmap algorithm that the rest of
    the IOMMU implementations use?

    http://lkml.org/lkml/2008/6/4/250
    --
    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: [ANNOUNCE] iommu-2.6.git tree

    On Sun, 19 Oct 2008 23:23:27 +0200
    Joerg Roedel wrote:

    > On Sun, Oct 19, 2008 at 02:21:14PM +0100, David Woodhouse wrote:
    > > I thought you and Thomas were working together, and I spoke to Thomas
    > > about it during the Kernel Summit. Unless I'm very much mistaken, he
    > > agreed that it makes sense to have a separate, real, git tree for
    > > cross-platform IOMMU-related work.

    >
    > Is there any cross-platform IOMMU-related work outside the Intel IOMMU
    > development?


    IA64 and PARISC uses the same IOMMU hardware but they duplicate the
    driver for them (the drivers are very similar). Calgary and POWER also
    have similar IOMMU drivers. But I don't think it's worth merging them.

    Unless a new cross-platform IOMMU git tree handles DMA-API changes,
    there is no point in having such new tree. There is very little
    non-architecture-specific IOMMU stuff.
    --
    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: [ANNOUNCE] iommu-2.6.git tree

    On Sun, 2008-10-19 at 23:14 +0200, Joerg Roedel wrote:
    > This is a reason for a seperate Intel IOMMU tree which is pulled by
    > Linus. But I don't think that this is a reason to take over control of
    > all IOMMU development.


    I have no intention of taking over control of anything, if I can
    possibly avoid it. The _less_ patch-monkey work I have to do, the
    happier I'll be. There's more to life than Jon's patch statistics.

    I'm perfectly happy for Ingo to pull my tree into his, as I keep saying.
    As long as it gets into linux-next, that's fine.

    When I discussed it with Thomas a few weeks ago, he seemed to be
    suggesting that creating a new tree was the best thing to do, but I'm
    more than happy to adapt.

    --
    David Woodhouse Open Source Technology Centre
    David.Woodhouse@intel.com Intel Corporation

    --
    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: [ANNOUNCE] iommu-2.6.git tree


    * David Woodhouse wrote:

    > On Sun, 2008-10-19 at 23:14 +0200, Joerg Roedel wrote:
    > > This is a reason for a seperate Intel IOMMU tree which is pulled by
    > > Linus. But I don't think that this is a reason to take over control of
    > > all IOMMU development.

    >
    > I have no intention of taking over control of anything, if I can
    > possibly avoid it. The _less_ patch-monkey work I have to do, the
    > happier I'll be. There's more to life than Jon's patch statistics.
    >
    > I'm perfectly happy for Ingo to pull my tree into his, as I keep
    > saying. As long as it gets into linux-next, that's fine.
    >
    > When I discussed it with Thomas a few weeks ago, he seemed to be
    > suggesting that creating a new tree was the best thing to do, but I'm
    > more than happy to adapt.


    Creating a new Git tree is a good thing to do in any case - as i
    expressed it to you earlier as well, repeatedly. I told it you a month
    ago and later as well. Here's that portion of my mail to you from Sept
    22:

    | > I'm also planning to create a separate git tree for iommu work,
    | > where we can all have direct access. It doesn't really live in the
    | > x86 tree.
    |
    | the separate git tree is sure useful for the Intel IOMMU bits.
    |
    | Note that this all affects the x86 tree very significantly so please
    | send pull requests to us like Joerg does it for the AMD-IOMMU bits and
    | then we'll integrate and send it upstream from there.

    A number of non-x86 and x86 contributors to various tip/* topics do that
    already and it's a great help to be able to pull Git trees, as it scales
    the maintenance overhead.

    We already do it for tip/sched/* topics and tip/tracing/* topics
    -neither of which has anything to do with the x86 trees, and all of
    these feed into linux-next independently of any x86 bits. We'd obviously
    pull from you and send it towards Linus. (Long term we want to
    eventually reach the kind of sub-maintainer setup that DaveM does so
    well with the networking tree.)

    There's tip/core/iommu for generic / non-x86 bits - should any such bits
    show up. And out of caution, despite all IOMMU work being currently
    centered around x86, we've got a separate tip/auto-iommu-next as well,
    integrated into linux-next independently of the x86 tree.

    What was not fine for you was to declare tip/auto-iommu-next the 'old'
    tree and to request a zapping of linux-next's auto-iommu-next
    integration, unilaterally.

    If all IOMMU developers and Andrew/Linus want that to happen and want
    you to maintain it all then sure i have no objections - but based on the
    history of this code there will be ongoing integration trouble as 90% of
    the current IOMMU activities are centered around x86 and is actually
    done by x86 developers, for obvious reasons. linux-next needs another
    source of integration trouble like a sore tooth.

    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/

  18. Re: [ANNOUNCE] iommu-2.6.git tree

    On Mon, 2008-10-20 at 10:52 +0200, Ingo Molnar wrote:
    > What was not fine for you was to declare tip/auto-iommu-next the 'old'
    > tree and to request a zapping of linux-next's auto-iommu-next
    > integration, unilaterally.


    I didn't ask for it to be removed. Stephen asked if he should remove it,
    and given my conversation with Thomas I said that I _believe_ that was
    the plan. After all, the old tree already didn't seem to exist any more,
    even though there were outstanding patches which need to be merged. But
    I made sure I didn't give a definitive answer to Stephen's question, and
    I made sure you and Thomas were both on Cc when I said it.

    If that was offensive to you, then I apologise.

    --
    David Woodhouse Open Source Technology Centre
    David.Woodhouse@intel.com Intel Corporation

    --
    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: [ANNOUNCE] iommu-2.6.git tree

    > The x86 maintainers are not responsible for IA64 patches AFAIK. The KVM
    > work will be merged by Avi.

    ^^^^^^^

    FYI: This part appears to have already happened:

    $ git log v2.6.27.. | grep KVM.*ia64
    KVM: ia64: Add intel iommu support for guests.
    KVM: ia64: add directed mmio range support for kvm guests
    KVM: ia64: Make pmt table be able to hold physical mmio entries.
    KVM: ia64: Add intel iommu support for guests.
    KVM: ia64: add directed mmio range support for kvm guests
    KVM: ia64: Make pmt table be able to hold physical mmio entries.
    KVM: ia64: add support for Tukwila processors
    KVM: ia64: Implement a uniform vps interface
    KVM: ia64: Implement kvm_arch_vcpu_ioctl_{set,get}_mpstate
    KVM: ia64: Enable virtio driver for ia64 in Kconfig
    KVM: ia64: add a dummy irq ack notification

    I have some extra ia64 bits queued in my tree (that are in today's
    linux-next tree tagged "next-20081020"). These parts build OK by
    themselves, but CONFIG_DMAR can't be turned on until the pieces that
    David has in his tree are merged too (e.g. the parts that make
    the driver work for systems where PAGESIZE may be something other
    than 4K).

    -Tony
    --
    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: [ANNOUNCE] iommu-2.6.git tree

    >IA64 and PARISC uses the same IOMMU hardware but they duplicate the
    >driver for them (the drivers are very similar). Calgary and POWER also
    >have similar IOMMU drivers. But I don't think it's worth merging them.


    If you are talking about IA64 HP ZX1, then it does have same IOMMU hardware as PARISC.

    But now David is pushing Intel VT-d IOMMU code for IA64. The hardware and driver are different from HP or PARISC. The hardware is same as x86 VT-d and the driver is ported from x86 IOMMU driver.

    Thanks.

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