Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756424Ab0BXKOL (ORCPT ); Wed, 24 Feb 2010 05:14:11 -0500 Received: from david.siemens.de ([192.35.17.14]:17291 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752651Ab0BXKOJ (ORCPT ); Wed, 24 Feb 2010 05:14:09 -0500 Message-ID: <4B84FBDB.1070006@siemens.com> Date: Wed, 24 Feb 2010 11:13:47 +0100 From: Jan Kiszka User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Avi Kivity CC: Thomas Gleixner , KVM , Gleb Natapov , RT , Linux Kernel Mailing List Subject: Re: [PATCH] KVM: x86: Kick VCPU outside PIC lock again References: <20100217135901.331576359@linutronix.de> <4B842A1F.50601@siemens.com> <4B84F466.2080009@siemens.com> <4B84F5D4.5020202@redhat.com> <4B84F765.5040209@siemens.com> <4B84F9AF.8060804@redhat.com> In-Reply-To: <4B84F9AF.8060804@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1494 Lines: 53 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/