From: "Liu, Yi L" <yi.l.liu@linux.intel.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: tianyu.lan@intel.com, kevin.tian@intel.com, yi.l.liu@intel.com,
mst@redhat.com, jasowang@redhat.com, qemu-devel@nongnu.org,
Peter Xu <peterx@redhat.com>,
alex.williamson@redhat.com, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [RESEND PATCH 2/6] memory: introduce AddressSpaceOps and IOMMUObject
Date: Fri, 22 Dec 2017 14:47:28 +0800 [thread overview]
Message-ID: <20171222064728.GA20627@sky-dev> (raw)
In-Reply-To: <20171220110110.GF5981@umbus.fritz.box>
On Wed, Dec 20, 2017 at 10:01:10PM +1100, David Gibson wrote:
> On Wed, Dec 20, 2017 at 02:32:42PM +0800, Liu, Yi L wrote:
> > On Mon, Dec 18, 2017 at 10:22:18PM +1100, David Gibson wrote:
> > > On Mon, Dec 18, 2017 at 05:17:35PM +0800, Liu, Yi L wrote:
> > > > On Mon, Dec 18, 2017 at 05:14:42PM +1100, David Gibson wrote:
> > > > > On Thu, Nov 16, 2017 at 04:57:09PM +0800, Liu, Yi L wrote:
[snip]
> > > Partly. Each PE has an address space which all devices in the PE see.
> > > Only some of that address space is mapped to system memory though,
> > > other parts are occupied by devices, others are unmapped.
> > >
> > > Only the parts mapped by the IOMMU vary between PEs - the other parts
> > > of the address space will be identical for all PEs on the host
> >
> > Thx, this comment addressed me well. This is different from what we have
> > on VT-d.
>
> Really? That's hard to believe. I'm pretty sure the VT-d IOMMU must
> have a range < 2^64, and anything on the bus outside that range I
> expect would be common between all domains. In particular I'd expect
> the BARs for other devices not to be remapped by the IOMMU (though
> they may be inaccessible on PCI-E due peer to peer transactions being
> blocked). As well as things above the IOMMU's range, I'd expect the
> region for 32-bit BARs to be common between all domains.
Sorry I misunderstood you. In each IOVA space, there is reserved range
, it is the BARs MMIO range. Such reservation is to avoid un-expected
Peer-To-Peer transaction. So regards to the IOVA space, all vendors should
be similar. So you are right~
Thanks,
Yi L
next prev parent reply other threads:[~2017-12-22 7:04 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-03 12:01 [Qemu-devel] [RESEND PATCH 0/6] Introduce new iommu notifier framework Liu, Yi L
2017-11-03 12:01 ` [Qemu-devel] [RESEND PATCH 1/6] memory: rename existing iommu notifier to be iommu mr notifier Liu, Yi L
2017-11-03 12:01 ` [Qemu-devel] [RESEND PATCH 2/6] memory: introduce AddressSpaceOps and IOMMUObject Liu, Yi L
2017-11-13 5:56 ` David Gibson
2017-11-13 8:28 ` Peter Xu
2017-11-14 0:59 ` David Gibson
2017-11-14 3:31 ` Peter Xu
2017-12-18 5:41 ` David Gibson
2017-11-16 8:57 ` Liu, Yi L
2017-12-18 6:14 ` David Gibson
2017-12-18 9:17 ` Liu, Yi L
2017-12-18 11:22 ` David Gibson
2017-12-20 6:32 ` Liu, Yi L
2017-12-20 11:01 ` David Gibson
2017-12-22 6:47 ` Liu, Yi L [this message]
2017-11-13 9:58 ` Liu, Yi L
2017-11-14 8:53 ` Auger Eric
2017-11-14 13:59 ` Liu, Yi L
2017-11-14 21:52 ` Auger Eric
2017-11-15 2:36 ` Liu, Yi L
2017-11-15 7:16 ` Peter Xu
2017-12-18 11:35 ` David Gibson
2017-12-20 6:47 ` Liu, Yi L
2017-12-20 11:18 ` David Gibson
2017-12-21 8:40 ` Liu, Yi L
2018-01-03 0:28 ` David Gibson
2018-01-04 9:40 ` Liu, Yi L
2018-01-12 10:25 ` Liu, Yi L
2018-01-16 6:04 ` David Gibson
2017-12-18 6:30 ` David Gibson
2017-11-14 10:21 ` Auger Eric
2017-11-14 14:20 ` Liu, Yi L
2017-12-18 11:38 ` David Gibson
2017-11-03 12:01 ` [Qemu-devel] [RESEND PATCH 3/6] intel_iommu: provide AddressSpaceOps.iommu_get instance Liu, Yi L
2017-11-03 12:01 ` [Qemu-devel] [RESEND PATCH 4/6] vfio: rename GuestIOMMU to be GuestIOMMUMR Liu, Yi L
2017-11-03 12:01 ` [Qemu-devel] [RESEND PATCH 5/6] vfio/pci: add notify framework based on IOMMUObject Liu, Yi L
2017-11-14 10:23 ` Auger Eric
2017-11-14 14:24 ` Liu, Yi L
2017-11-03 12:01 ` [Qemu-devel] [RESEND PATCH 6/6] vfio/pci: register vfio_iommu_bind_pasidtbl_notify notifier Liu, Yi L
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=20171222064728.GA20627@sky-dev \
--to=yi.l.liu@linux.intel.com \
--cc=alex.williamson@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=jasowang@redhat.com \
--cc=kevin.tian@intel.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=tianyu.lan@intel.com \
--cc=yi.l.liu@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).