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

--

[ message continues ]

Hi David,

On Sat, 18 Oct 2008 16:30:43 +0100 David Woodhouse <dwmw2@infradead.org> wr=

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?

--=20
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[ message continues ]

Yes. I don't use branches in public-facing repositories -- it's much

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

--

[ message continues ]

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

--

[ message continues ]

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

--

[ message continues ]

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

[ message continues ]

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

--

[ message continues ]

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

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 

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

[ message continues ]

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

There were patches outstanding which depended on both the interrupt

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

--

[ message continues ]

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

Joerg
--

[ message continues ]

^^^^^^^

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

[ message continues ]

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



--

[ message continues ]

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

Joerg

--

[ message continues ]

On Sun, 19 Oct 2008 23:23:27 +0200

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

[ message continues ]

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

[ message continues ]

On Mon, 20 Oct 2008 11:06:15 -0700


Yeah, I know that.

I just tried to point out that there is no cross-platform
(architecture independent) IOMMU stuff and David's new git tree should
be VT-d git tree, not a tree for architecture independent IOMMU stuff.
--

[ message continues ]

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

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

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

--

[ message continues ]

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

--

[ message continues ]

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 ...
[ message continues ]

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

--

[ message continues ]

On Sun, 19 Oct 2008 12:19:58 +0100

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

[ message continues ]