Re: [Qemu-devel] Linux kernel polling for QEMU

[Andrew Jones]

On Tue, Nov 29, 2016 at 05:13:27PM +0100, Paolo Bonzini wrote:
> 
> 
> On 29/11/2016 17:01, Andrew Jones wrote:
> > OK, it may be due to scheduling then. Below is the test case (for AArch64)
> > Also, I forgot to mention before that I can only see this with TCG, not
> > KVM. If ppoll is allowed to timeout, then the test will complete. If not,
> > then, as can be seen with strace, the iothread is stuck in ppoll, and the
> > test never completes.
> > 
> >  #include <asm/smp.h>
> >  volatile int ready;
> >  void set_ready(void) {
> >      ready = 1;
> >      while(1);
> >  }
> >  int main(void) {
> >      smp_boot_secondary(1, set_ready);
> >      while (!ready);
> >      return 0;
> >  }
> 
> Where is the test stuck?
>

Thanks for making me look, I was simply assuming we were in the while
loops above.

I couldn't get the problem to reproduce with access to the monitor,
but by adding '-d exec' I was able to see cpu0 was on the wfe in
smp_boot_secondary. It should only stay there until cpu1 executes the
sev in secondary_cinit, but it looks like TCG doesn't yet implement sev

 $ grep SEV target-arm/translate.c
        /* TODO: Implement SEV, SEVL and WFE.  May help SMP performance.

Changing the sev in kvm-unit-tests to a yield (which isn't the right
thing to do) "resolves" the issue.

Back to why the iothread's ppoll timeout is involved. Without the
timeout we never leave ppoll, so we never call qemu_mutex_lock_iothread,
which calls qemu_cpu_kick_no_halt, telling cpu1 to let cpu0 run again.

Anyway, I agree now that changing the infinite timeout to an arbitrary
finite timeout isn't the right solution. An fd that ppoll could select,
which would emulate a sched tick, would make a bit more sense, but we
probably don't want that either. Actually, this particular test case
covers such a small corner that we probably don't want to do anything
at all, except eventually implement sev for ARM TCG.

Apologies to Stefan for polluting his mail thread!

drew