KVM: x86: Kick VCPU outside PIC lock again
in [Kernel]
|
Prev: introduce sys_membarrier(): process-wide memory barrier (v9)
Next: [PATCH 2/4] x86-32: allow UP/SMP lock replacement in cmpxchg64 (v2)
From: Avi Kivity on 24 Feb 2010 04:50 On 02/24/2010 11:41 AM, Jan Kiszka wrote: > Thomas Gleixner wrote: > >> On Tue, 23 Feb 2010, Jan Kiszka wrote: >> >> >>> Thomas Gleixner wrote: >>> >>>> The i8254/i8259 locks need to be real spinlocks on preempt-rt. Convert >>>> them to raw_spinlock. No change for !RT kernels. >>>> >>> Doesn't fly for -rt anymore: pic_irq_update runs under this raw lock and >>> calls kvm_vcpu_kick which tries to wake_up some thread -> scheduling >>> while atomic. >>> >> Hmm, a wakeup itself is fine. Is that code waking a wake queue ? >> > Yes, it's a wake queue. > So what's the core issue? Is the lock_t in the wait_queue a sleeping mutex? > This restores the deferred VCPU kicking before 956f97cf. We need this > over -rt as wake_up* requires non-atomic context in this configuration. > > Seems sane, will apply once I understand why the current code fails. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jan Kiszka on 24 Feb 2010 05:00 Avi Kivity wrote: > On 02/24/2010 11:41 AM, Jan Kiszka wrote: >> Thomas Gleixner wrote: >> >>> On Tue, 23 Feb 2010, Jan Kiszka wrote: >>> >>> >>>> Thomas Gleixner wrote: >>>> >>>>> The i8254/i8259 locks need to be real spinlocks on preempt-rt. Convert >>>>> them to raw_spinlock. No change for !RT kernels. >>>>> >>>> Doesn't fly for -rt anymore: pic_irq_update runs under this raw lock and >>>> calls kvm_vcpu_kick which tries to wake_up some thread -> scheduling >>>> while atomic. >>>> >>> Hmm, a wakeup itself is fine. Is that code waking a wake queue ? >>> >> Yes, it's a wake queue. >> > > So what's the core issue? Is the lock_t in the wait_queue a sleeping mutex? Yep. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 24 Feb 2010 05:10 On 02/24/2010 11:54 AM, Jan Kiszka wrote: > Avi Kivity wrote: > >> On 02/24/2010 11:41 AM, Jan Kiszka wrote: >> >>> Thomas Gleixner wrote: >>> >>> >>>> On Tue, 23 Feb 2010, Jan Kiszka wrote: >>>> >>>> >>>> >>>>> Thomas Gleixner wrote: >>>>> >>>>> >>>>>> The i8254/i8259 locks need to be real spinlocks on preempt-rt. Convert >>>>>> them to raw_spinlock. No change for !RT kernels. >>>>>> >>>>>> >>>>> Doesn't fly for -rt anymore: pic_irq_update runs under this raw lock and >>>>> calls kvm_vcpu_kick which tries to wake_up some thread -> scheduling >>>>> while atomic. >>>>> >>>>> >>>> Hmm, a wakeup itself is fine. Is that code waking a wake queue ? >>>> >>>> >>> Yes, it's a wake queue. >>> >>> >> So what's the core issue? Is the lock_t in the wait_queue a sleeping mutex? >> > Yep. > I see. Won't we hit the same issue when we call pic functions from atomic context during the guest entry sequence? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 24 Feb 2010 05:20 On 02/24/2010 12:13 PM, Jan Kiszka wrote: > > >> I see. Won't we hit the same issue when we call pic functions from >> atomic context during the guest entry sequence? >> >> > If there are such call paths, for sure. What concrete path(s) do you > have in mind? > > vcpu_enter_guest() -> inject_pending_event() -> kvm_cpu_{has,get}_interrupt() -> various pic functions if you're unlucky. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jan Kiszka on 24 Feb 2010 05:20
Avi Kivity wrote: > On 02/24/2010 11:54 AM, Jan Kiszka wrote: >> Avi Kivity wrote: >> >>> On 02/24/2010 11:41 AM, Jan Kiszka wrote: >>> >>>> Thomas Gleixner wrote: >>>> >>>> >>>>> On Tue, 23 Feb 2010, Jan Kiszka wrote: >>>>> >>>>> >>>>> >>>>>> Thomas Gleixner wrote: >>>>>> >>>>>> >>>>>>> The i8254/i8259 locks need to be real spinlocks on preempt-rt. Convert >>>>>>> them to raw_spinlock. No change for !RT kernels. >>>>>>> >>>>>>> >>>>>> Doesn't fly for -rt anymore: pic_irq_update runs under this raw lock and >>>>>> calls kvm_vcpu_kick which tries to wake_up some thread -> scheduling >>>>>> while atomic. >>>>>> >>>>>> >>>>> Hmm, a wakeup itself is fine. Is that code waking a wake queue ? >>>>> >>>>> >>>> Yes, it's a wake queue. >>>> >>>> >>> So what's the core issue? Is the lock_t in the wait_queue a sleeping mutex? >>> >> Yep. >> > > I see. Won't we hit the same issue when we call pic functions from > atomic context during the guest entry sequence? > If there are such call paths, for sure. What concrete path(s) do you have in mind? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |