From: Joerg Roedel <joro@8bytes.org>
To: Auger Eric <eric.auger@redhat.com>
Cc: drjones@redhat.com, jason@lakedaemon.net, kvm@vger.kernel.org,
marc.zyngier@arm.com, punit.agrawal@arm.com, will.deacon@arm.com,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
diana.craciun@nxp.com, alex.williamson@redhat.com,
pranav.sawargaonkar@gmail.com,
linux-arm-kernel@lists.infradead.org, tglx@linutronix.de,
robin.murphy@arm.com, christoffer.dall@linaro.org,
eric.auger.pro@gmail.com
Subject: Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback
Date: Mon, 14 Nov 2016 16:31:50 +0100 [thread overview]
Message-ID: <20161114153149.GY2078@8bytes.org> (raw)
In-Reply-To: <634ac375-3507-6926-164f-e67f7c798c98@redhat.com>
Hi Eric,
On Fri, Nov 11, 2016 at 05:45:19PM +0100, Auger Eric wrote:
> On 11/11/2016 17:22, Joerg Roedel wrote:
> > So I think we need a way to tell userspace about the reserved regions
> > (per iommu-group) so that userspace knows where it can not map anything,
> Current plan is to expose that info through an iommu-group sysfs
> attribute, as you and Robin advised.
Great.
> > and VFIO can enforce that. But the right struct here is not an
> > iova-allocator rb-tree, a ordered linked list should be sufficient.
> I plan a linked list to store the reserved regions (P2P regions, MSI
> region, ...). get_dma_regions is called with a list local to a function
> for that. Might be needed to move that list head in the iommu_group to
> avoid calling the get_dm_regions again in the attribute show function?
You can re-use the get_dm_regions() call-back available in the iommu-ops
already. Just rename it and add a flag to it which tells the iommu-core
whether that region needs to be mapped or not.
> But to allocate the IOVAs within the MSI reserved region, I understand
> you don't want us to use the iova.c allocator, is that correct? We need
> an allocator though, even a very basic one based on bitmap or whatever.
> There potentially have several different physical MSI frame pages to map.
I don't get this, what do you need and address-allocator for?
Joerg
next prev parent reply other threads:[~2016-11-14 15:31 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-04 11:23 [RFC v2 0/8] KVM PCIe/MSI passthrough on ARM/ARM64 - Alt II Eric Auger
2016-11-04 11:23 ` [RFC v2 1/8] vfio: fix vfio_info_cap_add/shift Eric Auger
2016-11-04 11:24 ` [RFC v2 2/8] iommu/iova: fix __alloc_and_insert_iova_range Eric Auger
2016-11-10 15:22 ` Joerg Roedel
2016-11-10 15:41 ` Auger Eric
2016-11-04 11:24 ` [RFC v2 3/8] iommu/dma: Allow MSI-only cookies Eric Auger
2016-11-14 12:36 ` Robin Murphy
2016-11-14 23:23 ` Auger Eric
2016-11-15 14:52 ` Robin Murphy
2016-11-04 11:24 ` [RFC v2 4/8] iommu: Add a list of iommu_reserved_region in iommu_domain Eric Auger
2016-11-04 14:00 ` Robin Murphy
2016-11-10 11:22 ` Auger Eric
2016-11-10 11:54 ` Robin Murphy
2016-11-10 12:14 ` Auger Eric
2016-11-10 12:48 ` Robin Murphy
2016-11-10 15:37 ` Joerg Roedel
2016-11-10 15:42 ` Auger Eric
2016-11-04 11:24 ` [RFC v2 5/8] vfio/type1: Introduce RESV_IOVA_RANGE capability Eric Auger
2016-11-04 11:24 ` [RFC v2 6/8] iommu: Handle the list of reserved regions Eric Auger
2016-11-04 11:24 ` [RFC v2 7/8] iommu/vt-d: Implement add_reserved_regions callback Eric Auger
2016-11-04 11:24 ` [RFC v2 8/8] iommu/arm-smmu: implement " Eric Auger
2016-11-04 14:16 ` Robin Murphy
2016-11-10 15:46 ` Joerg Roedel
2016-11-10 15:57 ` Auger Eric
2016-11-10 16:13 ` Joerg Roedel
2016-11-10 18:00 ` Auger Eric
2016-11-11 11:42 ` Joerg Roedel
2016-11-11 15:47 ` Auger Eric
2016-11-11 16:22 ` Joerg Roedel
2016-11-11 16:45 ` Auger Eric
2016-11-14 15:31 ` Joerg Roedel [this message]
2016-11-14 16:08 ` Auger Eric
2016-11-14 16:20 ` Joerg Roedel
2016-11-14 16:57 ` Auger Eric
2016-11-10 16:07 ` Robin Murphy
2016-11-10 16:16 ` Joerg Roedel
2016-11-11 14:34 ` Robin Murphy
2016-11-11 15:03 ` Joerg Roedel
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=20161114153149.GY2078@8bytes.org \
--to=joro@8bytes.org \
--cc=alex.williamson@redhat.com \
--cc=christoffer.dall@linaro.org \
--cc=diana.craciun@nxp.com \
--cc=drjones@redhat.com \
--cc=eric.auger.pro@gmail.com \
--cc=eric.auger@redhat.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jason@lakedaemon.net \
--cc=kvm@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=pranav.sawargaonkar@gmail.com \
--cc=punit.agrawal@arm.com \
--cc=robin.murphy@arm.com \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.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).