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.
Paolo
