On 20.11.14 20:31, Suresh E. Warrier wrote: > > > On 11/20/2014 11:36 AM, Alexander Graf wrote: >> >> >> On 03.11.14 05:52, Paul Mackerras wrote: >>> From: "Suresh E. Warrier" <warrier@xxxxxxxxxxxxxxxxxx> >>> >>> The kvmppc_vcore_blocked() code does not check for the wait condition >>> after putting the process on the wait queue. This means that it is >>> possible for an external interrupt to become pending, but the vcpu to >>> remain asleep until the next decrementer interrupt. The fix is to >>> make one last check for pending exceptions and ceded state before >>> calling schedule(). >>> >>> Signed-off-by: Suresh Warrier <warrier@xxxxxxxxxxxxxxxxxx> >>> Signed-off-by: Paul Mackerras <paulus@xxxxxxxxx> >> >> I don't understand the race you're fixing here. Can you please explain it? >> > > When a virtual interrupt needs to be delivered to the guest, and the > virtual ICS state for the interrupt and virtual ICP state for the VCPU > allow for the VCPU to be immediately interrupted, we > 1. Set the BOOK3S_INTERRUPT_EXTERNAL_LEVEL bit in pending_exceptions. > 2. Call kvmppc_fast_vcpu_kick_hv(), which checks the wait queue at vcpu->wq > to wake the VCPU up. > > The caller of kvmppc_vcore_blocked() does the check for pending exceptions, but > there is a race condition here and we do need to check again after the VCPU > is put on the wait queue. I see. Thanks, applied to kvm-ppc-queue. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
