[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3] xen: make sure stop_machine_run() is always called in a tasklet

On 28.02.20 20:06, Andrew Cooper wrote:
On 28/02/2020 17:13, Juergen Gross wrote:
@@ -700,6 +688,32 @@ int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) 
buf, unsigned long len)
      return ret;
+int microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) buf, unsigned long len)
+    int ret;
+    struct ucode_buf *buffer;
+    if ( len != (uint32_t)len )
+        return -E2BIG;
+    if ( microcode_ops == NULL )
+        return -EINVAL;
+    buffer = xmalloc_flex_struct(struct ucode_buf, buffer, len);
+    if ( !buffer )
+        return -ENOMEM;
+    ret = copy_from_guest(buffer->buffer, buf, len);
+    if ( ret )
+    {
+        xfree(buffer);
+        return -EFAULT;
+    }
+    buffer->len = len;
+    return continue_hypercall_on_cpu(0, microcode_update_helper, buffer);

Any reason why cpu 0 here?  There is no restriction at the moment, and
running the tasklet on the current CPU is surely better than poking
CPU0's tasklet queue remotely, then interrupting it.

As stop_machine_run() is scheduling a tasklet on all other cpus it
doesn't really matter. In the end I don't really mind either way.

Everything else looks ok.  This adjustments could be done on commit to
save a v4.


P.S. Might it be sensible to have a continue_hypercall_in_tasklet()
wrapper which passes smp_processor_id() into continue_hypercall_on_cpu()?

When a second user is coming up, maybe.

The other would be continue_hypercall_on_bootcpu().


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.