[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] iommu / p2m: add a page_order parameter to iommu_map/unmap_page()
On 17/10/18 09:19, Paul Durrant wrote: > diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c > index 55df18501e..b264a97bd8 100644 > --- a/xen/arch/x86/mm/p2m-pt.c > +++ b/xen/arch/x86/mm/p2m-pt.c > @@ -683,41 +684,13 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, > mfn_t mfn, > { > ASSERT(rc == 0); > > - if ( iommu_use_hap_pt(p2m->domain) ) > - { > - if ( iommu_old_flags ) > - amd_iommu_flush_pages(p2m->domain, gfn, page_order); > - } > - else if ( need_iommu_pt_sync(p2m->domain) ) > - { > - dfn_t dfn = _dfn(gfn); > - > - if ( iommu_pte_flags ) > - for ( i = 0; i < (1UL << page_order); i++ ) > - { > - rc = iommu_map_page(p2m->domain, dfn_add(dfn, i), > - mfn_add(mfn, i), iommu_pte_flags); > - if ( unlikely(rc) ) > - { > - while ( i-- ) > - /* If statement to satisfy __must_check. */ > - if ( iommu_unmap_page(p2m->domain, > - dfn_add(dfn, i)) ) > - continue; > - > - break; > - } > - } > - else > - for ( i = 0; i < (1UL << page_order); i++ ) > - { > - int ret = iommu_unmap_page(p2m->domain, > - dfn_add(dfn, i)); > - > - if ( !rc ) > - rc = ret; > - } > - } > + if ( need_iommu_pt_sync(p2m->domain) ) > + rc = iommu_pte_flags ? > + iommu_map_page(d, _dfn(gfn), mfn, page_order, > + iommu_pte_flags) : > + iommu_unmap_page(d, _dfn(gfn), page_order); > + else if ( iommu_use_hap_pt(d) && iommu_old_flags ) > + amd_iommu_flush_pages(p2m->domain, gfn, page_order); This logically reverses the iommu_use_hap_pt(d)/need_iommu_pt_sync(p2m->domain) conditions. I'd be tempted confine this change to the else if ( need_iommu_pt_sync(p2m->domain) ) block. Tangentially related, calling amd_iommu_flush_pages() is a laying violation here because this is supposedly common code. In reality, it is the NPT code, so might perhaps be better named as p2m-npt.c. George? > } > > /* > diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c > index f1df1debc7..3fa559da01 100644 > --- a/xen/arch/x86/mm/p2m.c > +++ b/xen/arch/x86/mm/p2m.c > @@ -718,24 +718,8 @@ p2m_remove_page(struct p2m_domain *p2m, unsigned long > gfn_l, unsigned long mfn, > p2m_access_t a; > > if ( !paging_mode_translate(p2m->domain) ) > - { > - int rc = 0; > - > - if ( need_iommu_pt_sync(p2m->domain) ) > - { > - dfn_t dfn = _dfn(mfn); > - > - for ( i = 0; i < (1 << page_order); i++ ) > - { > - int ret = iommu_unmap_page(p2m->domain, dfn_add(dfn, i)); > - > - if ( !rc ) > - rc = ret; > - } > - } > - > - return rc; > - } > + return need_iommu_pt_sync(p2m->domain) ? > + iommu_unmap_page(p2m->domain, _dfn(mfn), page_order) : 0; TBH, I think this is harder to read than the non ternary alternative. > > ASSERT(gfn_locked_by_me(p2m, gfn)); > P2M_DEBUG("removing gfn=%#lx mfn=%#lx\n", gfn_l, mfn); > diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c > index 8b438ae4bc..40db9e7849 100644 > --- a/xen/drivers/passthrough/iommu.c > +++ b/xen/drivers/passthrough/iommu.c > @@ -305,50 +305,71 @@ void iommu_domain_destroy(struct domain *d) > } > > int iommu_map_page(struct domain *d, dfn_t dfn, mfn_t mfn, > - unsigned int flags) > + unsigned int page_order, unsigned int flags) > { > const struct domain_iommu *hd = dom_iommu(d); > - int rc; > + unsigned long i; > > if ( !iommu_enabled || !hd->platform_ops ) > return 0; > > - rc = hd->platform_ops->map_page(d, dfn, mfn, flags); > - if ( unlikely(rc) ) > + for ( i = 0; i < (1ul << page_order); i++ ) > { > - if ( !d->is_shutting_down && printk_ratelimit() ) > - printk(XENLOG_ERR > - "d%d: IOMMU mapping dfn %"PRI_dfn" to mfn %"PRI_mfn" > failed: %d\n", > - d->domain_id, dfn_x(dfn), mfn_x(mfn), rc); > + int ignored, rc = hd->platform_ops->map_page(d, dfn_add(dfn, i), > + mfn_add(mfn, i), > + flags); > > - if ( !is_hardware_domain(d) ) > - domain_crash(d); > + if ( unlikely(rc) ) > + { > + while (i--) Spaces, but you're also off-by-one when cleaning up i = 0. Wouldn't it be easier to reuse iommu_unmap_page() rather than opencode it? ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |