On Tue, May 30, 2017 at 04:26:34PM +0200, Paolo Bonzini wrote:
>
>
> On 30/05/2017 15:39, Andrew Jones wrote:
> > On Tue, May 30, 2017 at 02:13:34PM +0200, Paolo Bonzini wrote:
> > Yes, I know, I even wrote something similar to that already and it
> > works fine, *if* the calling cpu can always expect the target cpu
> > to eventually (for some value of eventually) run its code (the "other
> > side" code above). When I implemented it I decided that that code
> > implements an idle loop, i.e.
> >
> > void secondary_halt(void) <-- maybe rename to do_idle()
> > {
> > cpu = smp_processor_id();
> > set_cpu_idle(cpu, true);
> > for (;;) {
> > while (cpu_idle(cpu))
> > wfe();
> > ...
> > cb(opaque);
> > set_cpu_idle(cpu, true);
> > }
> > }
> >
> > This implies on_cpu*() must wait for a target cpu's currently running
> > task to finish, i.e., as I said above, no arbitrary preemption.
>
> Yes, that's okay.
>
> > So it's not as nice as an IPI solution that doesn't block an asynchronise
> > caller (possibly indefinitely), which would mean it doesn't actually
> > implement the semantics of on_cpu_async anyway.
>
> It's probably a bug anyway to have on_cpu_async while a previous
> on_cpu_async is running. If you look at x86 tests, on_cpu_async usually
> is followed by a busy wait for all CPUs to complete.
OK, I'll clean up my idle-loop wfe/sev series and post soon then.
Thanks,
drew
