Re: [PATCH -mm 0/3] convert IOMMUs to use iova
On Sat, Nov 03, 2007 at 02:05:39AM +0900, FUJITA Tomonori wrote: > This patchset convert the PPC64 IOMMU to use the iova code for free > area management. > > The IOMMUs ignores low level drivers' restrictions, the maximum > segment size and segment boundary. > > I fixed the former: > > http://thread.gmane.org/gmane.linux.scsi/35602 > > The latter makes the free area management complicated. I'd like to > convert IOMMUs to use the iova code (that intel-iommu introduced) > for free area management and enable iova to handle segment boundary > restrictions, rather than fixing all the IOMMUs' free area > management, In general it sounds like a great idea, but have you looked at what impact this has on the performance of the IO path? Cheers, Muli - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] aic94xx: fix SMP request DMA direction
On Sun, Sep 30, 2007 at 12:13:55AM -0700, Darrick J. Wong wrote: > Actually, SMP commands are used during device discovery to find > things attached to expanders, so it seems likely that "it blows up > almost immediately after loading the module" symptoms are a result > of this bug. > > That said, the bug that Jeff fixed resulted in extra permissions > (+w) being set for the SMP request buffer, so that's probably why > I've never seen any problems manifesting on x260/x3800 systems. > > (Unless the CalIOC2 has a write only mode?) It does (you can turn on each of the R and W bits in the TCE entry seperately) but we don't make use of it - we set it to either none, RO or RW. Cheers, Muli - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] aic94xx: fix SMP request DMA direction
On Fri, Sep 28, 2007 at 04:55:34PM -0700, Darrick J. Wong wrote: > On Thu, Sep 27, 2007 at 10:33:41PM -0400, Jeff Garzik wrote: > > > > Unless I'm missing something, the SMP request goes /to/ the PCI device :) > > > > Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> > > ACK; builds ok and SMP commands seem to work ok (not that they > didn't before). Could this explain some weirdness we were seeing with aic94xx and Calgary/CalIOC2 enabled, or are SMP commands not likely to be used in normal operation? We map the IOMMU entries differently for FROMDEVICE (RW) and TODEVICE(RO). Cheers, Muli -- SYSTOR 2007 --- 1st Annual Haifa Systems and Storage Conference 2007 http://www.haifa.il.ibm.com/Workshops/systor2007/ Oct 29, 2007: virtualization workshop | Oct 30, 2007: storage workshop - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] fix iommu sg list merge problem
On Wed, Sep 26, 2007 at 05:57:57PM +0900, FUJITA Tomonori wrote: > iommu code merges sg lists without considering lld's restrictions so > some llds need a workaround to split sg lists again. This patchset > fixes iommu to handle lld's max segment size limit properly. The patches look reasonable to me. > This patchset includes only the x86_64 iommu patch There are multiple x86-64 IOMMUs, but only GART is in-tree and supports merging. > but my git tree includes x86_64, ppc, ia64, parisc, and alpha > patches. As far as I know, thye are all the iommu code that merges > sg lists. The iommu patchse are only compile tested. > > > git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git iommu Do you think it will be possible to abstract the merging code into common code, rather than duplicating it for every IOMMU? Cheers, Muli - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17, 2007 at 01:05:03PM +0200, Jens Axboe wrote: > > FYI, here's the Calgary diff on top of the outstanding Calgary > > changes. > > When are these bits being merged into mainline? I'll hang on to this > version for helping me rebase the arch bits of chained sglists once > that happens. I sincerely hope they'll make 2.6.23 but Andi appears to have fallen into a black hole. Cheers, Muli - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, Jul 16, 2007 at 11:47:23AM +0200, Jens Axboe wrote:
> This prepares x86-64 for sg chaining support.
>
> Additional improvements/fixups for pci-gart from
> Benny Halevy <[EMAIL PROTECTED]>
>
> Cc: [EMAIL PROTECTED]
> Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
> ---
> arch/x86_64/kernel/pci-calgary.c | 25 --
> arch/x86_64/kernel/pci-gart.c| 63 -
> arch/x86_64/kernel/pci-nommu.c |5 ++-
Calgary and nommu bits are:
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
FYI, here's the Calgary diff on top of the outstanding Calgary
changes.
diff -r 8642809f9e33 arch/x86_64/kernel/pci-calgary.c
--- a/arch/x86_64/kernel/pci-calgary.c Mon Jul 16 09:38:14 2007 +0300
+++ b/arch/x86_64/kernel/pci-calgary.c Tue Jul 17 13:33:24 2007 +0300
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -387,31 +388,32 @@ static void calgary_unmap_sg(struct devi
struct scatterlist *sglist, int nelems, int direction)
{
struct iommu_table *tbl = find_iommu_table(dev);
+ struct scatterlist *s;
+ int i;
if (!translate_phb(to_pci_dev(dev)))
return;
- while (nelems--) {
+ for_each_sg(sglist, s, nelems, i) {
unsigned int npages;
- dma_addr_t dma = sglist->dma_address;
- unsigned int dmalen = sglist->dma_length;
+ dma_addr_t dma = s->dma_address;
+ unsigned int dmalen = s->dma_length;
if (dmalen == 0)
break;
npages = num_dma_pages(dma, dmalen);
iommu_free(tbl, dma, npages);
- sglist++;
}
}
static int calgary_nontranslate_map_sg(struct device* dev,
struct scatterlist *sg, int nelems, int direction)
{
+ struct scatterlist *s;
int i;
- for (i = 0; i < nelems; i++ ) {
- struct scatterlist *s = &sg[i];
+ for_each_sg(sg, s, nelems, i) {
BUG_ON(!s->page);
s->dma_address = virt_to_bus(page_address(s->page) +s->offset);
s->dma_length = s->length;
@@ -423,6 +425,7 @@ static int calgary_map_sg(struct device
int nelems, int direction)
{
struct iommu_table *tbl = find_iommu_table(dev);
+ struct scatterlist *s;
unsigned long vaddr;
unsigned int npages;
unsigned long entry;
@@ -431,8 +434,7 @@ static int calgary_map_sg(struct device
if (!translate_phb(to_pci_dev(dev)))
return calgary_nontranslate_map_sg(dev, sg, nelems, direction);
- for (i = 0; i < nelems; i++ ) {
- struct scatterlist *s = &sg[i];
+ for_each_sg(sg, s, nelems, i) {
BUG_ON(!s->page);
vaddr = (unsigned long)page_address(s->page) + s->offset;
@@ -457,9 +459,9 @@ static int calgary_map_sg(struct device
return nelems;
error:
calgary_unmap_sg(dev, sg, nelems, direction);
- for (i = 0; i < nelems; i++) {
- sg[i].dma_address = bad_dma_address;
- sg[i].dma_length = 0;
+ for_each_sg(sg, s, nelems, i) {
+ s->dma_address = bad_dma_address;
+ s->dma_length = 0;
}
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17, 2007 at 10:51:23AM +0200, Jens Axboe wrote: > On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: > > On Tue, Jul 17, 2007 at 09:38:59AM +0200, Jens Axboe wrote: > > > > > On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: > > > > > > The Xen and Calgary bits are mutually exclusive, so hopefully (a) > > > > will not be held up on account of the Xen merge (or for any other > > > > reason... CalIOC2 machines which are out there won't boot without > > > > it if CONFIG_CALGARY_IOMMU is enabled). > > > > > > Do you have any comments for the patch to calgary (the mail you are > > > replying to)? > > > > It looks ok, I just didn't want to ACK it before testing (I'm paranoid > > that way). > > That's certainly understandable! Can you mail me an ack once you've had > a chance to test it? Yep, taking it for a spin now. Cheers, Muli - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17, 2007 at 09:38:59AM +0200, Jens Axboe wrote: > On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: > > The Xen and Calgary bits are mutually exclusive, so hopefully (a) > > will not be held up on account of the Xen merge (or for any other > > reason... CalIOC2 machines which are out there won't boot without > > it if CONFIG_CALGARY_IOMMU is enabled). > > Do you have any comments for the patch to calgary (the mail you are > replying to)? It looks ok, I just didn't want to ACK it before testing (I'm paranoid that way). Cheers, Muli - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, Jul 16, 2007 at 01:34:27PM -0700, Andrew Morton wrote: > > I'll keep rebasing sglist and the other branches I pull into for-akpm, > > so you can just re-enable the for-akpm pull when the a) is true. > > Andi's tree is very out of date and is about to be damaged (to what > extent I don't yet know) by a xen merge. I don't know if a) is > going to happen. The Xen and Calgary bits are mutually exclusive, so hopefully (a) will not be held up on account of the Xen merge (or for any other reason... CalIOC2 machines which are out there won't boot without it if CONFIG_CALGARY_IOMMU is enabled). Cheers, Muli - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Proposals to change the way all drivers work with SCSI commands
On Fri, May 11, 2007 at 01:33:41PM -0500, James Bottomley wrote: > Right at the moment, we're planning to clean up the way SCSI drivers > process commands. The proposals are essentially: > > 1. Get rid of the now unnecessary map_single path (every command is > either zero transfer or scatter/gather) > 2. use accessors to manipulate the SG lists (mainly so that we can > alter the implementation without affecting the drivers) > > It strikes me that in all of this, we could also consider doing the DMA > mapping inside the mid layer (instead of in every driver). This is > essentially what libata is already doing ... leading to confusion in > SCSI drivers that use libata for SATA. > > So what do people think about this? Yes please. It will be easier to modify the DMA API interface to better support hypervisors and other "DMA mapping heavy" users if it's localized to the mid-layer rather than spread out in drivers. Cheers, Muli - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/6] bidi support: request dma_data_direction
On Tue, Jan 23, 2007 at 03:45:00PM +0200, Benny Halevy wrote:
> >> +static inline int dma_uni_dir(enum dma_data_direction dir)
> >> +{
> >> + return (dir == DMA_TO_DEVICE) || (dir == DMA_FROM_DEVICE) ||
> >> + (dir == DMA_NONE);
> >> +}
> >
> > While this doesn't look very useful. Why is "DMA_NONE" a uni-dir? I
> > suggest replacing this with an open coded (dir != DMA_BIDIRECTIONAL).
>
> The idea was to be resilient to invalid values. (dir != DMA_BIDIRECTIONAL)
> is fine of course, but I'd add a BUG_ON such as (dir < 0 || dir >
> DMA_BIDIRECTIONAL)
If DMA_NONE isn't actually allowed here, you can use valid_dma_direction().
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/6] bidi support: request dma_data_direction
On Mon, Jan 22, 2007 at 01:21:28AM +0200, Boaz Harrosh wrote:
> - Introduce a new enum dma_data_direction data_dir member in struct request.
> and remove the RW bit from request->cmd_flag
Some architecture use 'enum dma_data_direction' and some 'int
dma_data_direction'. The consensus was to move to int over
time. Please use 'int dma_data_direction'.
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index ff203c4..abbca7b 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -13,6 +13,28 @@ enum dma_data_direction {
> DMA_NONE = 3,
> };
>
> +static inline int dma_write_dir(enum dma_data_direction dir)
> +{
> + return (dir == DMA_TO_DEVICE) || (dir == DMA_BIDIRECTIONAL);
> +}
"write" can mean "write to device" or "write to memory", depending on
context. Not exactly something which should be a generic
helper. Rename to 'dma_to_device(int dir)'?
> +static inline int dma_uni_dir(enum dma_data_direction dir)
> +{
> + return (dir == DMA_TO_DEVICE) || (dir == DMA_FROM_DEVICE) ||
> +(dir == DMA_NONE);
> +}
While this doesn't look very useful. Why is "DMA_NONE" a uni-dir? I
suggest replacing this with an open coded (dir != DMA_BIDIRECTIONAL).
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
