Re: [PATCH kvm-unit-tests 0/3] arm/arm64: smp: prepare for on_cpu

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 30, 2017 at 02:13:34PM +0200, Paolo Bonzini wrote:
> 
> 
> On 29/05/2017 15:58, Andrew Jones wrote:
> > Paolo inspired me to add x86's on_cpu and on_cpu_asynch to ARM's API.
> > I messed around with it a while, but haven't really settled on what
> > I want to do. I played with the following approaches:
> >  - wfe/sev, requires the concept of an idle state and knowing that the
> >    target CPU is in that state - i.e. no arbitrary preemption.
> 
> WFE really is just a power-save NOP.  I think you'd do something like
> 
>    spin_lock(&dest->ipi_lock);
>    assert(dest->ipi_cb == NULL);
>    dest->ipi_cb = fn;
>    dest->ipi_opaque = opaque;
>    spin_unlock(&dest->ipi_lock);
>    asm("dsb; sev");
>    while (dest->ipi_cb != NULL)
>      asm("wfe");
> 
> and on the other side:
> 
>    while (dest->ipi_cb == NULL)
>       asm("wfe");
>    spin_lock(&dest->ipi_lock);
>    cb = dest->ipi_cb;
>    opaque = dest->ipi_opaque;
>    dest->ipi_cb = NULL;
>    spin_unlock(&dest->ipi_lock);
>    asm("dsb; sev");
>    cb(opaque);

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.

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.  However the IPI solution
requires the GIC, which may or may not be in the expected state after a
unit test mucks with it...

Right now I think I should just wait until the need arises for something
like on_cpu{_async}, and then implement it. That way I'll be sure it
provides the needed functionality.

Thanks,
drew



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux