With the removal of update_xen_mappings() there's no need anymore for a
2nd error code variable to transiently hold the IOMMU unmap return
value.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
I have to admit that I was tempted to get rid of PAGE_ORDER_4K at this
occasion, as it feels awkward to me to have such in clearly x86-only
code.

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2470,12 +2470,7 @@ static int cleanup_page_mappings(struct
         struct domain *d = page_get_owner(page);
 
         if ( d && unlikely(need_iommu_pt_sync(d)) && is_pv_domain(d) )
-        {
-            int rc2 = iommu_legacy_unmap(d, _dfn(mfn), 1u << PAGE_ORDER_4K);
-
-            if ( !rc )
-                rc = rc2;
-        }
+            rc = iommu_legacy_unmap(d, _dfn(mfn), 1u << PAGE_ORDER_4K);
 
         if ( likely(!is_special_page(page)) )
         {

On 09/06/2022 16:39, Jan Beulich wrote:
> With the removal of update_xen_mappings() there's no need anymore for a
> 2nd error code variable to transiently hold the IOMMU unmap return
> value.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Oh - I'd not even spotted that simplification.

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

> ---
> I have to admit that I was tempted to get rid of PAGE_ORDER_4K at this
> occasion, as it feels awkward to me to have such in clearly x86-only
> code.

Happy for that to go too.

~Andrew