From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Mackerras Date: Wed, 20 Feb 2013 00:41:11 +0000 Subject: Re: [PATCH 3/9] KVM: PPC: Book3S: Add kernel emulation for the XICS interrupt controller Message-Id: <20130220004111.GB8102@iris.ozlabs.ibm.com> List-Id: References: <20130216045116.GC21288@iris.ozlabs.ibm.com> <1361227407.25178.1@snotra> In-Reply-To: <1361227407.25178.1@snotra> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Scott Wood Cc: Alexander Graf , kvm@vger.kernel.org, kvm-ppc@vger.kernel.org On Mon, Feb 18, 2013 at 04:43:27PM -0600, Scott Wood wrote: > On 02/15/2013 10:51:16 PM, Paul Mackerras wrote: > >The KVM_CREATE_IRQCHIP_ARGS ioctl says that you want emulation of a > >specific interrupt controller architecture connected to the vcpus' > >external interrupt inputs. In that sense it's explicit, compared to a > >generic "create device" ioctl that could be for any device. > > Hooking up to the CPU's interrupt lines is implicit in creating an > MPIC (and I'm fine with changing that), not in creating any device. > I don't see how it's worse than being implicit in calling > KVM_CREATE_IRQCHIP_ARGS (which doesn't allow for cascaded irqchips). First, KVM_CREATE_IRQCHIP_ARGS specifies the overall architecture of the interrupt control subsystem, so yes it does allow for cascaded controllers. Secondly, the difference is that if you see a KVM_CREATE_IRQCHIP_ARGS call, you know that the vcpus' interrupt inputs will be driven by kernel code. If you see a KVM_CREATE_DEVICE call, you don't know that; they might be, or they might not be. > >You're doing a round trip to userspace for every MPIC register access > >by the guest? Seriously? > > No. Accesses by the guest get handled in the kernel. Accesses in > QEMU, including MSIs generated by virtio, get forwarded to the > kernel. OK, I missed the path where that gets done, then. > >It would be the current task priority. I assume MPIC maintains a > >16-bit map of the interrupt priorities in service, so that would need > >to be added. > > We don't maintain such a map in the emulation code. We have a Oh, so how do you handle EOI of nested interrupts? How do you know what to reset the CPU priority to in that case? > per-CPU bitmap of the actual interrupt sources pending/active, which > is another attribute that would need to be added in order to support > migration on MPIC. Not really, that can be recomputed from the sources easily enough. Paul.