From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: in-kernel interrupt controller steering Date: Wed, 6 Mar 2013 07:28:42 -0500 (EST) Message-ID: <125812475.3190138.1362572922012.JavaMail.root@redhat.com> References: <1777B6DD-B341-4531-BE43-7B0161B1D093@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, Stuart Yoder , Scott Wood , Paul Mackerras , Peter Maydell To: Alexander Graf Return-path: In-Reply-To: <1777B6DD-B341-4531-BE43-7B0161B1D093@suse.de> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org > > Alex, would the PPC patches let you run with in-kernel "LAPICs" > > and userspace "IOAPICs"? If so, the new model would not be a > > problem with QEMU at all. > > The split on PPC isn't that clean. The MPIC doesn't split it at all > for example. There we only have an "IOAPIC" without a "LAPIC". So > setting the irqchip type to MPIC would be a nop. > > For XICS, we would have something similar to a LAPIC. We would > however have to communicate with that piece to tell it that > interrupts are pending or not. I suppose this might be doable > through the ONE_REG interface that Paul implemented, but I'm not > sure. Paul, can you confirm? > I don't really think doing such a split makes sense though :). > > > The problem would only start if KVM_SET_IRQCHIP_TYPE (new name of > > KVM_CREATE_IRQCHIP_ARGS) forced you to later call > > KVM_CREATE_DEVICE. > > Ah, I see. I don't see why it would. The fact that there is a "LAPIC" > doesn't mean that the per-vcpu SET_INTERRUPT ioctl stops working. So > if SET_IRQCHIP_TYPE(!none) breaks user-space interrupt controller > emulation I would consider that a bug. If there's agreement that KVM_SET_IRQCHIP_TYPE doesn't force subsequent KVM_CREATE_DEVICE calls (for CPU interrupt controllers that's because they're controlled via ONE_REG and not DEVICE_ATTR), I think we're fine. Paolo