From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH v3 13/13] xen/iommu: smmu: Advertise when
 the SMMU support coherent table walk
Date: Fri, 20 Feb 2015 14:13:00 +0000
Message-ID: <1424441580.30924.262.camel@citrix.com>
References: <1422643768-23614-1-git-send-email-julien.grall@linaro.org>
	<1422643768-23614-14-git-send-email-julien.grall@linaro.org>
	<1424439284.30924.233.camel@citrix.com> <54E73F93.3000306@linaro.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1YOoKH-00062Q-OP
	for xen-devel@lists.xenproject.org; Fri, 20 Feb 2015 14:13:05 +0000
In-Reply-To: <54E73F93.3000306@linaro.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Julien Grall <julien.grall@linaro.org>
Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com
List-Id: xen-devel@lists.xenproject.org

On Fri, 2015-02-20 at 14:07 +0000, Julien Grall wrote:
> On 20/02/15 13:34, Ian Campbell wrote:
> > On Fri, 2015-01-30 at 18:49 +0000, Julien Grall wrote:
> >> @@ -2896,6 +2911,16 @@ static __init int arm_smmu_dt_init(struct dt_device_node *dev,
> >>  	if ( !rc )
> >>  		iommu_set_ops(&arm_smmu_iommu_ops);
> >>  
> >> +	/*
> >> +	 * The last added SMMU is the first element of arm_smmu_devices.
> >> +	 * It's not necessary to take the lock because only the boot CPU is
> >> +	 * initialized the SMMU devices.
> > 
> > Why is only the last added SMMU of interest? Do we not need to take the
> > union and/or intersection of them all?
> 
> It's already the case. The function arm_smmu_dt_init is called on every
> SMMU. So the last added SMMU is the one we are currently added.

Why do we not just have it in our hand and have to go scrobbling round
in a list then?

> > Perhaps the code which calls iommu_set_feature should gain an else which
> > calls iommu_clear_feature, and between them they can ensure that
> > platform_features is correctly updated?
> 
> iommu_{set,clear}_feature is a generic code and per-domain.

Ah, ok.

> The main issue is if we add device protected by SMMU which doesn't have
> coherent walk, we have to browse the page table and clean the cache.
> 
> So we have to know at boot time that one of the SMMU doesn't have
> coherent walk.

Rather than making assumptions about the list ordering and if we can't
just get hold of the smmu pointer directly from arm_smmu_dt_init then
I'd prefer an explicit walk of the list at some appropriate point after
everything has been registered up.

Ian.