From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC][PATCH 0/3]: Fixes to IRQ routing Date: Wed, 09 Jun 2010 14:02:28 +0300 Message-ID: <4C0F74C4.90308@redhat.com> References: <1276019703-18136-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, mtosatti@redhat.com To: Chris Lalancette Return-path: Received: from mx1.redhat.com ([209.132.183.28]:56057 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752883Ab0FILCa (ORCPT ); Wed, 9 Jun 2010 07:02:30 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o59B2Tju028317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 Jun 2010 07:02:30 -0400 Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com [10.35.255.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o59B2TKE005708 for ; Wed, 9 Jun 2010 07:02:29 -0400 In-Reply-To: <1276019703-18136-1-git-send-email-clalance@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 06/08/2010 08:55 PM, Chris Lalancette wrote: > As we've discussed previously, here is a series of patches to > fix some of the IRQ routing issues we have in KVM. With this series > in place I was able to successfully kdump a RHEL-5 64-bit, and RHEL-6 > 32- and 64-bit guest on CPU's other than the BSP. RHEL-5 32-bit kdump still > does not work; it gets stuck on "Checking 'hlt' instruction". However, > it does that both before and after this series, so there is something > else going on there that I still have to debug. > > I also need to change the "kvm_migrate_pit_timer" function to migrate the > timer over to the last CPU that handled the timer interrupt, on the > theory that that particlar CPU is likely to handle the timer interrupt again > in the near future. > > The other outstanding question about these patches is how to setup the > workqueue. As it stands I have a single workqueue for all guests. However, > for efficiency reasons we may want to have one workqueue per guest. Opinions? > Perhaps a singlethreaded workqueue per guest? Or perhaps just schedule_work(), and let the kernel worry about the details? -- error compiling committee.c: too many arguments to function