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.
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()?
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
