While for now PV domains have a host P2M associated with them and hence using XENMEM_get_pod_target on such may not be a real problem, calling p2m_pod_set_mem_target() for a PV domain is surely wrong, even if benign at present.
Signed-off-by: Jan Beulich <[email protected]> --- While the output of the two subfunctions is stale by the time the caller accesses it, I wonder in how far it is helpful to provide potentially inconsistent values, due to the lack of any respective locking. It just so happens that "get" has no in-tree caller at all (years ago I did propose it to be exposed to guests themselves, with no real decision taken either way), while of the two "set" callers neither cares about the output. https://lists.xenproject.org/archives/html/xen-devel/2014-01/msg01524.html https://lists.xenproject.org/archives/html/xen-devel/2014-02/msg02154.html Furthermore for "set" I also find it concerning that page-alloc-lock protected data is being accessed without holding that lock. Both d->max_pages and the result of domain_tot_pages() can change in parallel. Then again I wonder whether "set" shouldn't be restricted to before the guest gets actually started. --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -4786,7 +4786,9 @@ long arch_memory_op(unsigned long cmd, X if ( d == NULL ) return -ESRCH; - if ( cmd == XENMEM_set_pod_target ) + if ( !is_hvm_domain(d) ) + rc = -EINVAL; + else if ( cmd == XENMEM_set_pod_target ) rc = xsm_set_pod_target(XSM_PRIV, d); else rc = xsm_get_pod_target(XSM_PRIV, d);
