[PATCH 1/2] x86/mm: XENMEM_{get,set}_pod_target are restricted to HVM domains

[Jan Beulich <jbeulich@xxxxxxxx>]

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 <jbeulich@xxxxxxxx>
---
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);