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

[Jürgen Groß <jgross@xxxxxxxx>]

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