On 09.01.2012, at 23:41, Yoder Stuart-B08248 wrote: > >>>> Hrm. This will return on signal. So if the guest sends an idle hcall, >>>> then user space gets a random signal, we'll continue executing the >>>> guest CPU, getting us out of idle even though the guest didn't expect it, >>>> since the guest >> really wants to get an interrupt after the idle hcall. >>> >>> Is that a problem though? Won't it be just like a spurious interrupt where >>> the guest would wake up, see that there is nothing to do, and then >>> go idle again? What is your concern here? >> >> We would have changed state by enabling interrupts in the asm code. > > What do you mean here, could you elaborate?
> > +#ifdef CONFIG_KVM_GUEST > +/* > + * r3 contains the pointer to in[8] > + * r4 contains the pointer to out[8] > + * r5 contains the hcall vendor and nr > + * r6 contains the handler which send hcall > + */ > +_GLOBAL(e500_ev_idle) entering with interrupts disabled > + rlwinm r7,r1,0,0,31-THREAD_SHIFT /* current thread_info */ > + lwz r8,TI_LOCAL_FLAGS(r7) /* set napping bit */ > + ori r8,r8,_TLF_NAPPING /* so when we take an exception */ > + stw r8,TI_LOCAL_FLAGS(r7) /* it will return to our caller */ > + wrteei 1 enable interrupts > + mtctr r6 > + bctr call hypercall, race occurs, return to caller with interrupts enabled Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
