Re: alpha iommu fixes

[David S. Miller]

Andrea Arcangeli writes:
 > I just given you a test case that triggers on sparc64 in earlier email.

If you are talking about the bttv card:

1) I showed you in a private email that I calculated the
   maximum possible IOMMU space that one could allocate
   to bttv cards in a fully loaded Sunfire sparc64 system
   to be between 300MB and 400MB.  This is assuming that
   every PCI slot contained a bttv card, and it still
   used only ~%35 of the available IOMMU resources.

2) It currently doesn't even use the portable APIs yet anyways,
   so effectively it is not supported on sparc64.

The only other examples you showed were theoretical, for cards and
configurations that simply are not supported or cannot happen
on sparc64 with current kernels.

 > Chris just given a real world example of applications where that kind of
 > design is useful and there are certainly other kind of apps where that
 > kind of hardware design can be useful too.
 > 
 > A name of an high end pci32 card that AFIK can trigger those bugs is the
 > Quadrics which is a very nice piece of hardware btw.

I think such designs which gobble up a gig or so of DMA mappings on
pci32 are not useful in the slightest.  These cards really ought
to be using dual address cycles, ie. 64-bit PCI addressing.  It is
the same response you would give to someone trying to obtain 3 or more
gigabytes of user address space in a process on x86, right?  You might
respond to that person "What you really need is x86-64." for example
:-)

To me, from this perspective, the Quadrics sounds instead like a very
broken piece of hardware.  And in any event, is there even a Quadrics
driver for sparc64? :-)  (I'm a free software old-fart, so please
excuse my immediate association between "high end" and "proprietary"
:-)

Finally Andrea, have you even begun to consider the possible
starvation cases once we make this a resource allocation which can
fail under "normal" conditions.  Maybe the device eatins all the IOMMU
entries, immediately obtains a new mapping when he frees any mapping,
effectively keeping out all other devices.

This may be easily solved, I don't know.

But this along with the potential scsi layer issues, are basically the
reasons I'm trying hard to keep the API as it is right now for 2.4.x
Changing this in 2.4.x is going to open up Pandora's Box, really.

Later,
David S. Miller
[e-mail]