[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. ~Andrew 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(). Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |