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