From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] Search the LAPIC's for one that will accept a PIC interrupt. Date: Wed, 23 Jun 2010 14:37:27 +0300 Message-ID: <4C21F1F7.4020109@redhat.com> References: <1277134180-9806-1-git-send-email-clalance@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Chris Lalancette Return-path: Received: from mx1.redhat.com ([209.132.183.28]:1027 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751232Ab0FWLh3 (ORCPT ); Wed, 23 Jun 2010 07:37:29 -0400 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5NBbSLV001996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 23 Jun 2010 07:37:29 -0400 Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com [10.35.255.11]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o5NBbSwI007584 for ; Wed, 23 Jun 2010 07:37:28 -0400 In-Reply-To: <1277134180-9806-1-git-send-email-clalance@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 06/21/2010 06:29 PM, Chris Lalancette wrote: > Older versions of 32-bit linux have a "Checking 'hlt' instruction" > test where they repeatedly call the 'hlt' instruction, and then > expect a timer interrupt to kick the CPU out of halt. This happens > before any LAPIC or IOAPIC setup happens, which means that all of > the APIC's are in virtual wire mode at this point. Unfortunately, > the current implementation of virtual wire mode is hardcoded to > only kick the BSP, so if a crash+kexec occurs on a different > vcpu, it will never get kicked. > > This patch makes pic_unlock() do the equivalent of > kvm_irq_delivery_to_apic() for the IOAPIC code. That is, it runs > through all of the vcpus looking for one that is in virtual wire > mode. In the normal case where LAPICs and IOAPICs are configured, > this won't be used at all. In the bootstrap phase of a modern > OS, before the LAPICs and IOAPICs are configured, this will have > exactly the same behavior as today; VCPU0 is always looked at > first, so it will always get out of the loop after the first > iteration. This will only go through the loop more than once > during a kexec/kdump, in which case it will only do it a few times > until the kexec'ed kernel programs the LAPIC and IOAPIC. > Applied, thanks. -- error compiling committee.c: too many arguments to function