From: Roland Dreier <rdreier@cisco.com>
To: mst@mellanox.co.il, general@lists.openfabrics.org
Cc: Lukas Hejtmanek <xhejtman@ics.muni.cz>,
xen-devel@lists.xensource.com, Keir Fraser <keir@xensource.com>
Subject: [ofa-general] mthca use of dma_sync_single is bogus
Date: Mon, 09 Jul 2007 14:16:19 -0700 [thread overview]
Message-ID: <adalkdpxopo.fsf@cisco.com> (raw)
It seems the problems running mthca in a Xen domU have uncovered a bug
in mthca: mthca uses dma_sync_single in mthca_arbel_write_mtt_seg()
and mthca_arbel_map_phys_fmr() to sync the MTTs that get written.
However, Documentation/DMA-API.txt says:
void
dma_sync_single(struct device *dev, dma_addr_t dma_handle, size_t size,
enum dma_data_direction direction)
synchronise a single contiguous or scatter/gather mapping. All the
parameters must be the same as those passed into the single mapping
API.
and mthca is *not* following this clear rule: it is trying to sync
only a subrange of the mapping. Later on in the document, there is:
void
dma_sync_single_range(struct device *dev, dma_addr_t dma_handle,
unsigned long offset, size_t size,
enum dma_data_direction direction)
does a partial sync. starting at offset and continuing for size. You
must be careful to observe the cache alignment and width when doing
anything like this. You must also be extra careful about accessing
memory you intend to sync partially.
but that is in a section dealing with non-consistent memory so it's
not entirely clear to me whether it's kosher to use this as mthca
wants.
The other alternative is to put the MTT table in coherent memory just
like the MPT table. That might be the best solution I suppose...
Michael, anyone else, thoughts on this?
- R.
next reply other threads:[~2007-07-09 21:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-09 21:16 Roland Dreier [this message]
2007-07-09 21:29 ` [ofa-general] mthca use of dma_sync_single is bogus Roland Dreier
2007-07-09 21:36 ` Keir Fraser
2007-07-09 21:31 ` [ofa-general] " Keir Fraser
2007-07-09 21:31 ` Roland Dreier
2007-07-09 21:39 ` Michael S. Tsirkin
2007-07-10 6:48 ` Roland Dreier
2007-07-10 7:15 ` Michael S. Tsirkin
2007-07-10 15:33 ` Roland Dreier
2007-07-10 17:11 ` Michael S. Tsirkin
2007-07-10 18:09 ` Roland Dreier
2007-07-10 18:30 ` Michael S. Tsirkin
2007-07-10 19:25 ` Roland Dreier
2007-07-18 13:36 ` Michael S. Tsirkin
2007-07-18 15:12 ` Roland Dreier
2007-07-10 14:14 ` Lukas Hejtmanek
2007-07-10 18:06 ` Roland Dreier
2007-07-10 19:00 ` Lukas Hejtmanek
2007-07-10 19:08 ` Roland Dreier
2007-07-10 19:16 ` Lukas Hejtmanek
2007-07-10 19:24 ` Roland Dreier
2007-07-10 19:36 ` Lukas Hejtmanek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=adalkdpxopo.fsf@cisco.com \
--to=rdreier@cisco.com \
--cc=general@lists.openfabrics.org \
--cc=keir@xensource.com \
--cc=mst@mellanox.co.il \
--cc=xen-devel@lists.xensource.com \
--cc=xhejtman@ics.muni.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.