From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tbdt1-0002wE-Em for qemu-devel@nongnu.org; Thu, 22 Nov 2012 16:00:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tbdt0-0006Nw-Fe for qemu-devel@nongnu.org; Thu, 22 Nov 2012 16:00:39 -0500 Received: from gate.crashing.org ([63.228.1.57]:33125) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tbdt0-0006Nk-7R for qemu-devel@nongnu.org; Thu, 22 Nov 2012 16:00:38 -0500 Message-ID: <1353618020.17856.43.camel@pasglop> From: Benjamin Herrenschmidt Date: Fri, 23 Nov 2012 08:00:20 +1100 In-Reply-To: <50ADFDA8.9010003@redhat.com> References: <1353460020.17856.25.camel@pasglop> <50ADFDA8.9010003@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Subject: Re: [Qemu-devel] Interrupt controller updates List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Alexander Graf , kvm@vger.kernel.org, Peter Maydell , Jan Kiszka , "qemu-devel@nongnu.org" , David Gibson On Thu, 2012-11-22 at 11:25 +0100, Paolo Bonzini wrote: > > Again, from memory, you were volunteered to do the initial x86 > change so > > we could piggy back on it :-) Or do I remember wrong ? > > Please suggest an API, then we can work out the x86 changes. I can > volunteer myself, but I wasn't in the BOF so I need something more > concrete. Oh it's simple enough initially, just move the ioctl call from generic kvm init to machine init. The problem is then to add an argument, since that essentially means changing the ioctl number, but we need that for all archs where the interrupt subsystem can be fundamentally different based on the platform. Basically, what was discussed in the BOF was that we split the init: * The existing ioctl moves to early machine init (before VCPUs) and gets that argument to define the type of interrupt subsystem to use. It causes powerpc to instanciate ICPs per VCPUs for example. On archs that don't have a per-vcpu structure (equivalent of local APIC or ICP), all it does is enable subsequent irq related ioctls to work (it's just an "enable" flag). * A new ioctl is used to actually instanciate external interrupt controllers (GIC on ARM, ICS for ppc/pseries, MPIC for ppc/mpic, ...). This is used later by the PIC code itself when the former ioctl has enabled "in kernel PIC" * A new ioctl is used for platforms that need to be able to adjust the base address of a PIC (arm/GIC, ppc/mpic) We have other things to look at (mostly along the MSI routing calls in qemu that need to be changed to be PCI bridge hooks populated by the platform) but that's the starting point. Cheers, Ben.