Benjamin Herrenschmidt wrote:
On Tue, 2008-02-26 at 00:43 -0500, Mark Lord wrote:
I suppose so. I don't remember all of the details, but iirc, it has to
do with crossing 64K boundaries. Some controllers can't handle it.
It's not only the _size_ of the segments, it's their alignment.
The iommu
Mark Lord wrote:
Benjamin Herrenschmidt wrote:
On Tue, 2008-02-26 at 00:43 -0500, Mark Lord wrote:
I suppose so. I don't remember all of the details, but iirc, it has to
do with crossing 64K boundaries. Some controllers can't handle it.
It's not only the _size_ of the segments, it's their
As an aside, ISTR tomo-san was working on eliminating the need for the
/2 by tackling the details on the IOMMU side...
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Jeff Garzik wrote:
Mark Lord wrote:
Jeff,
We had a discussion here today about IOMMUs,
and they *never* split sg list entries -- they only ever *merge*.
And this happens only after the block layer has
already done merging while respecting q-seg_boundary_mask.
So worst case, the IOMMU may
Jeff Garzik wrote:
As an aside, ISTR tomo-san was working on eliminating the need for the
/2 by tackling the details on the IOMMU side...
..
Yes, tomo-san just led a nice detailed discussion of it here at LSF'08,
and he agrees that even today it shouldn't affect us that way.
Cheers
-
To
On Mon, 2008-02-25 at 19:15 -0500, Jeff Garzik wrote:
Mark Lord wrote:
Jeff,
We had a discussion here today about IOMMUs,
and they *never* split sg list entries -- they only ever *merge*.
And this happens only after the block layer has
already done merging while respecting
Benjamin Herrenschmidt wrote:
On Mon, 2008-02-25 at 19:15 -0500, Jeff Garzik wrote:
Mark Lord wrote:
Jeff,
We had a discussion here today about IOMMUs,
and they *never* split sg list entries -- they only ever *merge*.
And this happens only after the block layer has
already done merging while
Mark Lord wrote:
Benjamin Herrenschmidt wrote:
..
The split wasn't done by the iommu. The split was done by the IDE code
itself to handle the stupid 64k crossing thingy. If it's done
differently now, it might be possible to remove it, I haven't looked.
..
The block layer uses
The block layer uses seg_boundary_mask to ensure that we never have
to split them again in the LLD.
A very long time ago, when I wrote the IDE DMA code, this was not the case.
Not good enough, still, because the boundaries can change due to the
iommu merging, thus the split must be re-done.
James B. suggests that we stick a WARN_ON() into libata to let us
know if that precondition is violated. Sounds like an easy thing to do
for a couple of -rc cycles someday.
If the block layer gives us a 32k block aligned on a 32k boundary
(aligned), we have no guarantee that the iommu will
Benjamin Herrenschmidt wrote:
James B. suggests that we stick a WARN_ON() into libata to let us
know if that precondition is violated. Sounds like an easy thing to do
for a couple of -rc cycles someday.
If the block layer gives us a 32k block aligned on a 32k boundary
(aligned), we have no
On Mon, 2008-02-25 at 23:38 -0500, Mark Lord wrote:
Benjamin Herrenschmidt wrote:
James B. suggests that we stick a WARN_ON() into libata to let us
know if that precondition is violated. Sounds like an easy thing to do
for a couple of -rc cycles someday.
If the block layer gives us
Benjamin Herrenschmidt wrote:
On Mon, 2008-02-25 at 23:38 -0500, Mark Lord wrote:
Benjamin Herrenschmidt wrote:
James B. suggests that we stick a WARN_ON() into libata to let us
know if that precondition is violated. Sounds like an easy thing to do
for a couple of -rc cycles someday.
If the
On Tue, 2008-02-26 at 00:43 -0500, Mark Lord wrote:
I suppose so. I don't remember all of the details, but iirc, it has to
do with crossing 64K boundaries. Some controllers can't handle it.
It's not only the _size_ of the segments, it's their alignment.
The iommu will not keep
14 matches
Mail list logo
