[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 13/13] xen/iommu: smmu: Advertise when the SMMU support coherent table walk
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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |