> From: 'j...@8bytes.org' [mailto:j...@8bytes.org]
> Sent: Wednesday, December 12, 2018 5:54 PM
>
> Hi Kevin,
>
> On Wed, Dec 12, 2018 at 09:31:27AM +, Tian, Kevin wrote:
> > > From: 'j...@8bytes.org'
> > > Sent: Monday, December 10, 2018 4:58 PM
> > > These represent whether the device toget
Hi Kevin,
On Wed, Dec 12, 2018 at 09:31:27AM +, Tian, Kevin wrote:
> > From: 'j...@8bytes.org'
> > Sent: Monday, December 10, 2018 4:58 PM
> > These represent whether the device together with the IOMMU support
> > them,
> > basically whether these features are usable via the IOMMU-API.
>
> "d
> From: 'j...@8bytes.org'
> Sent: Monday, December 10, 2018 4:58 PM
>
> Hi Kevin,
>
> On Mon, Dec 10, 2018 at 02:06:44AM +, Tian, Kevin wrote:
> > Can I interpret above as that you agree with the aux domain concept (i.e.
> one
> > device can be linked to multiple domains) in general, and now
On Tue, Dec 11, 2018 at 01:35:23PM +, Jean-Philippe Brucker wrote:
> > /* So we need a iommu_aux_detach_all()? */
>
> This could be useful for device drivers that want to do bulk cleanup on
> device removal. If they rely on Function Level Reset to disable PASID
> states for example, they c
On Tue, Dec 11, 2018 at 06:34:23PM +, Jean-Philippe Brucker wrote:
> The cost of enabling those features for a device does seem negligible.
> For the SMMU we need to allocate about 70k of additional memory for the
> initial PASID table, but enabling the PASID cap shouldn't add any
> overhead ot
On 10/12/2018 08:57, 'j...@8bytes.org' wrote:
> Hi Kevin,
>
> On Mon, Dec 10, 2018 at 02:06:44AM +, Tian, Kevin wrote:
>> Can I interpret above as that you agree with the aux domain concept (i.e. one
>> device can be linked to multiple domains) in general, and now we're just
>> trying
>> to a
On 07/12/2018 10:29, 'j...@8bytes.org' wrote:
> Hi,
>
> On Mon, Nov 26, 2018 at 07:29:45AM +, Tian, Kevin wrote:
>> btw Baolu just reminded me one thing which is worthy of noting here.
>> 'primary' vs. 'aux' concept makes sense only when we look from a device
>> p.o.v. That binding relationshi
Hi Lu Baolu,
On Mon, Dec 10, 2018 at 10:57:22AM +0800, Lu Baolu wrote:
> > /* Check if a device supports a given feature of the IOMMU-API */
> > bool iommu_dev_has_feature(struct device *dev, enum iommu_dev_features
> > *feat);
>
> Here we pass in a pointer of "enum iommu_dev_features",
Hi Kevin,
On Mon, Dec 10, 2018 at 02:06:44AM +, Tian, Kevin wrote:
> Can I interpret above as that you agree with the aux domain concept (i.e. one
> device can be linked to multiple domains) in general, and now we're just
> trying
> to address the remaining open in API level?
Yes, I thouht a
Hi Joerg,
On 12/7/18 6:29 PM, 'j...@8bytes.org' wrote:
Hi,
On Mon, Nov 26, 2018 at 07:29:45AM +, Tian, Kevin wrote:
btw Baolu just reminded me one thing which is worthy of noting here.
'primary' vs. 'aux' concept makes sense only when we look from a device
p.o.v. That binding relationship
> From: 'j...@8bytes.org' [mailto:j...@8bytes.org]
> Sent: Friday, December 7, 2018 6:29 PM
>
> Hi,
>
> On Mon, Nov 26, 2018 at 07:29:45AM +, Tian, Kevin wrote:
> > btw Baolu just reminded me one thing which is worthy of noting here.
> > 'primary' vs. 'aux' concept makes sense only when we lo
Hi,
On Mon, Nov 26, 2018 at 07:29:45AM +, Tian, Kevin wrote:
> btw Baolu just reminded me one thing which is worthy of noting here.
> 'primary' vs. 'aux' concept makes sense only when we look from a device
> p.o.v. That binding relationship is not (*should not be*) carry-and-forwarded
> cross
> From: Tian, Kevin
> Sent: Monday, November 26, 2018 11:01 AM
[...]
> > aux-domain is just a normal domain (struct iommu_domain), what
> > happens
> > when a domain that was used as a primary domain and has bound
> > aux-domains to it, is bound with iommu_aux_domain_attach() to another
> > domain?
> From: j...@8bytes.org [mailto:j...@8bytes.org]
> Sent: Friday, November 23, 2018 7:21 PM
>
> On Wed, Nov 21, 2018 at 12:40:44PM +0800, Lu Baolu wrote:
> > Can you please elaborate a bit more about the concept of subdomains?
> > From my point of view, an aux-domain is a normal un-managed domain
>
Hi Joerg,
On 11/23/18 7:21 PM, j...@8bytes.org wrote:
On Wed, Nov 21, 2018 at 12:40:44PM +0800, Lu Baolu wrote:
Can you please elaborate a bit more about the concept of subdomains?
From my point of view, an aux-domain is a normal un-managed domain which
has a PASID and could be attached to any
Hi Jean-Philippe,
On Wed, Nov 21, 2018 at 07:05:13PM +, Jean-Philippe Brucker wrote:
> For the moment though, I think we should allow device drivers to use the
> DMA-API at the same time as SVA.
Yeah, that makes sense.
> If a device driver has to map a management ring buffer for example,
> i
Hi Kevin,
On Thu, Nov 22, 2018 at 08:39:19AM +, Tian, Kevin wrote:
> I agree special action needs to be taken for everything else (other than
> DMA-API), but the point that I didn't get is why the action must be based
> a new SVA-type domain, instead of extending default domain with SVA
> capa
On Wed, Nov 21, 2018 at 12:40:44PM +0800, Lu Baolu wrote:
> Can you please elaborate a bit more about the concept of subdomains?
> From my point of view, an aux-domain is a normal un-managed domain which
> has a PASID and could be attached to any ADIs through the aux-domain
> specific attach/detach
> From: j...@8bytes.org [mailto:j...@8bytes.org]
> Sent: Monday, November 12, 2018 10:56 PM
>
> Hi Jean-Philippe,
>
> On Thu, Nov 08, 2018 at 06:29:42PM +, Jean-Philippe Brucker wrote:
> > (1) My initial approach would have been to use the same page tables for
> > the default_domain and this
On 12/11/2018 14:55, j...@8bytes.org wrote:
> Hi Jean-Philippe,
>
> On Thu, Nov 08, 2018 at 06:29:42PM +, Jean-Philippe Brucker wrote:
>> (1) My initial approach would have been to use the same page tables for
>> the default_domain and this new domain, but it might be precisely what
>> you wer
Hi Joerg,
On 11/8/18 12:43 AM, j...@8bytes.org wrote:
Hi,
On Wed, Nov 07, 2018 at 11:40:30AM +0800, Lu Baolu wrote:
Hi Joerg,
On 11/7/18 12:25 AM, j...@8bytes.org wrote:
Nowadays, we can find PASID granular DMA translation on both ARM and x86
platforms. With PASID granular DMA translation sup
Hi Jean-Philippe,
On Thu, Nov 08, 2018 at 06:29:42PM +, Jean-Philippe Brucker wrote:
> (1) My initial approach would have been to use the same page tables for
> the default_domain and this new domain, but it might be precisely what
> you were trying to avoid with this new proposal: a device at
Hi,
On 06/11/2018 16:25, j...@8bytes.org wrote:
> On Mon, Oct 22, 2018 at 12:50:56PM +0100, Robin Murphy wrote:
>> To me, that sounds like a very good argument for having separate "attach as
>> primary domain" and "attach as aux domain" APIs.
>
> I agree with that, overloading iommu_attach_device
On Wed, 7 Nov 2018 17:43:23 +0100
"j...@8bytes.org" wrote:
> Hi,
>
> On Wed, Nov 07, 2018 at 11:40:30AM +0800, Lu Baolu wrote:
> > Hi Joerg,
> >
> > On 11/7/18 12:25 AM, j...@8bytes.org wrote:
> > Nowadays, we can find PASID granular DMA translation on both ARM and x86
> > platforms. With PASID
Hi,
On Wed, Nov 07, 2018 at 11:40:30AM +0800, Lu Baolu wrote:
> Hi Joerg,
>
> On 11/7/18 12:25 AM, j...@8bytes.org wrote:
> Nowadays, we can find PASID granular DMA translation on both ARM and x86
> platforms. With PASID granular DMA translation supported in system iommu, if
> a device divides it
Hi Joerg,
On 11/7/18 12:25 AM, j...@8bytes.org wrote:
On Mon, Oct 22, 2018 at 12:50:56PM +0100, Robin Murphy wrote:
To me, that sounds like a very good argument for having separate "attach as
primary domain" and "attach as aux domain" APIs.
I agree with that, overloading iommu_attach_device()
On Mon, Oct 22, 2018 at 12:50:56PM +0100, Robin Murphy wrote:
> To me, that sounds like a very good argument for having separate "attach as
> primary domain" and "attach as aux domain" APIs.
I agree with that, overloading iommu_attach_device() to support
aux-domains is not going to be a maintainab
Hi,
On 10/23/18 12:48 AM, Jordan Crouse wrote:
On Fri, Oct 19, 2018 at 07:11:52PM +0100, Jean-Philippe Brucker wrote:
(2) Allocate a domain and attach it to the device.
dom = iommu_domain_alloc()
iommu_attach_device(dom, dev)
I still have concerns about this part, which ar
Hi,
On 10/23/18 12:03 AM, Jean-Philippe Brucker wrote:
#1: Given that PASID is a system wide resource, during boot iommu driver needs
to scan and set the max PASID to be no more than min(iommu_supported_max_pasid)
of all available IOMMU's.
#2: In addition if any device supports less than the ch
> From: Raj, Ashok
> Sent: Wednesday, October 24, 2018 1:17 AM
>
> >
> > But that's not reason enough to completely disable PASID for the
> > device,
> > it could be the only one bound to that process, or PASID could be
> > only
> > used privately by the host device driver.
>
> Agree, there could
On Mon, 2018-10-22 at 17:03 +0100, Jean-Philippe Brucker wrote:
> On 22/10/2018 11:07, Raj, Ashok wrote:
> > > For my own convenience I've been using the SVA infrastructure
> > > since
> > > I already had the locking and IOMMU ops in place. The
> > > proposed
> > > interface is also mis
On 22/10/2018 12:50, Robin Murphy wrote:
> To me, that sounds like a very good argument for having separate "attach
> as primary domain" and "attach as aux domain" APIs. Say a driver wants
> to use multiple aux domains itself to isolate logically-separate
> transaction streams, but still also needs
On Fri, Oct 19, 2018 at 07:11:52PM +0100, Jean-Philippe Brucker wrote:
> (2) Allocate a domain and attach it to the device.
>
> dom = iommu_domain_alloc()
> iommu_attach_device(dom, dev)
>
> I still have concerns about this part, which are highlighted by the
> messy changes o
On 22/10/2018 11:07, Raj, Ashok wrote:
>> For my own convenience I've been using the SVA infrastructure since
>> I already had the locking and IOMMU ops in place. The proposed
>> interface is also missing min_pasid and max_pasid parameters, which
>> could be needed by device drivers
On Mon, Oct 22, 2018 at 12:50:56PM +0100, Robin Murphy wrote:
> On 22/10/2018 07:53, Tian, Kevin wrote:
> >>From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> >>Sent: Saturday, October 20, 2018 2:12 AM
> >>
> >>This is a first prototype adding auxiliary domain support to Arm SMMUv
On 22/10/2018 07:53, Tian, Kevin wrote:
From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
Sent: Saturday, October 20, 2018 2:12 AM
This is a first prototype adding auxiliary domain support to Arm SMMUv3,
following Lu Baolu's latest proposal for IOMMU aware mediated devices
[1].
On Fri, Oct 19, 2018 at 07:11:52PM +0100, Jean-Philippe Brucker wrote:
> This is a first prototype adding auxiliary domain support to Arm SMMUv3,
> following Lu Baolu's latest proposal for IOMMU aware mediated devices
> [1]. It works, but the attach() API still doesn't feel right. See (2)
> below.
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Saturday, October 20, 2018 2:12 AM
>
> This is a first prototype adding auxiliary domain support to Arm SMMUv3,
> following Lu Baolu's latest proposal for IOMMU aware mediated devices
> [1]. It works, but the attach() API
Hi Jean,
On 2018/10/20 2:11, Jean-Philippe Brucker wrote:
This is a first prototype adding auxiliary domain support to Arm SMMUv3,
following Lu Baolu's latest proposal for IOMMU aware mediated devices
[1]. It works, but the attach() API still doesn't feel right. See (2)
below.
Patch 1 adapts io
This is a first prototype adding auxiliary domain support to Arm SMMUv3,
following Lu Baolu's latest proposal for IOMMU aware mediated devices
[1]. It works, but the attach() API still doesn't feel right. See (2)
below.
Patch 1 adapts iommu.c to the current proposal for auxiliary domains.
Patches
40 matches
Mail list logo
