[PATCH 2/2][4.17?] x86: wire up VCPUOP_register_vcpu_time_memory_area for 32-bit guests

[Jan Beulich <jbeulich@xxxxxxxx>]

Forever sinced its introduction VCPUOP_register_vcpu_time_memory_area
was available only to native domains. Linux, for example, would attempt
to use it irrespective of guest bitness (including in its so called
PVHVM mode) as long as it finds XEN_PVCLOCK_TSC_STABLE_BIT set (which we
set only for clocksource=tsc, which in turn needs engaging via command
line option).

Fixes: a5d39947cb89 ("Allow guests to register secondary vcpu_time_info")
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
---
Is it actually correct for us to do cross-vCPU updates of the area here
(and also in the native counterpart as well as for runstate area
updates)? The virtual address may be valid for the given vCPU only, but
may be mapped to something else on the current vCPU (yet we only deal
with it not being mapped at all). Note how HVM code already calls
update_vcpu_system_time() only when v == current.

I'm surprised by Linux not using the secondary area in a broader
fashion. But I'm also surprised that they would only ever register an
area for vCPU 0.

--- a/xen/arch/x86/x86_64/domain.c
+++ b/xen/arch/x86/x86_64/domain.c
@@ -58,6 +58,26 @@ compat_vcpu_op(int cmd, unsigned int vcp
         break;
     }
 
+    case VCPUOP_register_vcpu_time_memory_area:
+    {
+        struct compat_vcpu_register_time_memory_area area = { .addr.p = 0 };
+
+        rc = -EFAULT;
+        if ( copy_from_guest(&area.addr.h, arg, 1) )
+            break;
+
+        if ( area.addr.h.c != area.addr.p ||
+             !compat_handle_okay(area.addr.h, 1) )
+            break;
+
+        rc = 0;
+        guest_from_compat_handle(v->arch.time_info_guest, area.addr.h);
+
+        force_update_vcpu_system_time(v);
+
+        break;
+    }
+
     case VCPUOP_send_nmi:
     case VCPUOP_get_physid:
         rc = do_vcpu_op(cmd, vcpuid, arg);