[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 02.03.20 10:06, Jan Beulich wrote:
On 29.02.2020 06:47, Jürgen Groß wrote:
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.

I think any case where we can avoid assigning special meaning
to CPU 0 is helpful. While we won't get to being able to offline
the BSP any time soon, we shouldn't put more road blocks on the
path there.

As I said: fine with me. Shall I resend or can this be done while


Xen-devel mailing list



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