From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: in-kernel interrupt controller steering Date: Wed, 06 Mar 2013 14:41:04 +0100 Message-ID: <51374770.5040405@redhat.com> References: <469599439.3185295.1362572055225.JavaMail.root@redhat.com> <1777B6DD-B341-4531-BE43-7B0161B1D093@suse.de> <20130306131424.GR11223@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Graf , kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, Stuart Yoder , Scott Wood , Paul Mackerras , Peter Maydell To: Gleb Natapov Return-path: In-Reply-To: <20130306131424.GR11223@redhat.com> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org Il 06/03/2013 14:14, Gleb Natapov ha scritto: >>>> 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. >> > For x86 this is the case though. I do not see how it can't be. If > LAPIC is emulated in userspace SET_INTERRUPT is used to pass IRQ > vector that should be handled as a result of LAPIC emulation. SET_IRQCHIP_TYPE creates the LAPICs; it would indeed break userspace LAPIC emulation because the LAPICs would not cause userspace exits anymore. However, it need not mandate the usage of an in-kernel IOAPIC or PIC though. KVM_INTERRUPT, the docs say, "is only useful if in-kernel local APIC or equivalent is not used", but it is really only useful for if in-kernel *IOAPIC* is not used. The userspace IOAPIC can use it to inject the interrupts to the in-kernel LAPIC. So, it would be possible to create the IOAPIC or PIC separately with KVM_CREATE_DEVICE, and have the userspace devices inject the interrupts with KVM_IRQ_LINE_STATUS (PIC->IOAPIC) or KVM_INTERRUPT (IOAPIC->LAPIC). Paolo