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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
