From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tbe6g-0005cG-Mx for qemu-devel@nongnu.org; Thu, 22 Nov 2012 16:14:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tbe6f-00025z-IU for qemu-devel@nongnu.org; Thu, 22 Nov 2012 16:14:46 -0500 Received: from mail-ie0-f173.google.com ([209.85.223.173]:39231) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tbe6f-00025N-DC for qemu-devel@nongnu.org; Thu, 22 Nov 2012 16:14:45 -0500 Received: by mail-ie0-f173.google.com with SMTP id e13so2336418iej.4 for ; Thu, 22 Nov 2012 13:14:44 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1353618020.17856.43.camel@pasglop> References: <1353460020.17856.25.camel@pasglop> <50ADFDA8.9010003@redhat.com> <1353618020.17856.43.camel@pasglop> Date: Thu, 22 Nov 2012 21:14:43 +0000 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] Interrupt controller updates List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: Alexander Graf , kvm@vger.kernel.org, Jan Kiszka , "qemu-devel@nongnu.org" , David Gibson , Paolo Bonzini On 22 November 2012 21:00, Benjamin Herrenschmidt wrote: > 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. I cynically suspect there may need to be some disentangling of x86/qemu code assumptions about what happens when, in order to do this "just move" step :-) > 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" For ARM we could move to use this but it would just be for the benefit of nicer fallback behaviour (you could say "no in kernel GIC" if the user runs qemu with a guest CPU which doesn't have a GIC, rather than having to exit saying "incompatible options" if 'in-kernel irqchip' and 'cpu with no irqchip' were both specified). > * 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 the ABI for this already in the kvm/arm patches which are heading into final review, by the way. -- PMM