From: hch@lst.de (hch@lst.de)
Subject: phys_addr_t instead of dma_addr_t for nvme_dev->cmb_dma_addr
Date: Wed, 11 Jan 2017 10:06:11 +0100 [thread overview]
Message-ID: <20170111090611.GC7350@lst.de> (raw)
In-Reply-To: <1484122522.26936.9.camel@mellanox.com>
On Wed, Jan 11, 2017@08:15:23AM +0000, Haggai Eran wrote:
> If the BAR is smaller than (offset + size) then any address that is
> outside the BAR must be treated by the device as if it is not in the
> CMB (otherwise some other devices / host memory will simply be
> inaccessible by the NVMe device).?
Yes. I so wish the CMB design wasn't so messed up and we'd just have
a separate BAR with a relative index for it. Maybe we'll need to
propose a CMBv2 in the working group, at least for the proposed new
extensions :)
> > I think this would only happen if we're behind a bridge with a
> > smaller
> > window than BAR.
>
> I'm pretty sure that the bridge window must contain the underlying
> device BARs. If it can't contain them, they can be simply left
> disabled.
Exactly.
> I'm not talking about DMA translation. I'm talking about MMIO
> translation. From what I understand this can happen on POWER systems.
> The physical addresses for MMIO that are used by the CPU are different
> from the ones that are used on the PCIe bus.
As far as I know MMIO translation is absolutely usual for IOMMUs.
That being said my knowledge of IOMMUs is mostly form before Intel
and AMD chipset added them and thus from the RISC/IA64 world.
next prev parent reply other threads:[~2017-01-11 9:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-05 10:20 phys_addr_t instead of dma_addr_t for nvme_dev->cmb_dma_addr Max Gurtovoy
2017-01-05 11:02 ` Haggai Eran
2017-01-05 18:39 ` Jon Derrick
2017-01-08 8:55 ` Haggai Eran
2017-01-09 21:54 ` Jon Derrick
2017-01-11 8:15 ` Haggai Eran
2017-01-11 9:06 ` hch [this message]
2017-01-11 15:36 ` Jon Derrick
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=20170111090611.GC7350@lst.de \
--to=hch@lst.de \
/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.