On 13.10.2025 12:15, Penny Zheng wrote:
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -1396,6 +1396,7 @@ int __mem_sharing_unshare_page(struct domain *d,
>      return rc;
>  }
>  
> +#ifdef CONFIG_MGMT_HYPERCALLS
>  int relinquish_shared_pages(struct domain *d)
>  {
>      int rc = 0;
> @@ -1452,6 +1453,7 @@ int relinquish_shared_pages(struct domain *d)
>      p2m_unlock(p2m);
>      return rc;
>  }
> +#endif /* CONFIG_MGMT_HYPERCALLS */
>  
>  static int range_share(struct domain *d, struct domain *cd,
>                         struct mem_sharing_op_range *range)

Is this necessary? Shouldn't MEM_SHARING as a whole become dependent upon
MGMT_HYPERCALLS, then also covering XENMEM_sharing_op? (The same will already
implicitly happen for MEM_PAGING, due to its VM_EVENT dependency.)

> --- a/xen/arch/x86/mm/paging.c
> +++ b/xen/arch/x86/mm/paging.c
> @@ -768,6 +768,7 @@ void paging_vcpu_teardown(struct vcpu *v)
>          shadow_vcpu_teardown(v);
>  }
>  
> +#ifdef CONFIG_MGMT_HYPERCALLS
>  /* Call when destroying a domain */
>  int paging_teardown(struct domain *d)
>  {
> @@ -794,6 +795,7 @@ int paging_teardown(struct domain *d)
>  
>      return rc;
>  }
> +#endif /* CONFIG_MGMT_HYPERCALLS */
>  
>  /* Call once all of the references to the domain have gone away */
>  void paging_final_teardown(struct domain *d)

This is irritating, and could hence have done with some clarification in the
description (to aid review, if nothing else): On the surface, why would
paging_teardown() need excluding, but paging_vcpu_teardown() and
paging_final_teardown() would (need to) stay? Yes, the latter two are used
on failure paths of certain functions. (Same e.g. for domain_teardown() and
hence arch_domain_teardown().)

Jan

Reply via email to