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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel