On 23.04.2013, at 08:38, Paul Mackerras wrote: > On Fri, Apr 19, 2013 at 04:06:26PM +0200, Alexander Graf wrote: >> Now that all the irq routing and irqfd pieces are generic, we can expose >> real irqchip support to all of KVM's internal helpers. >> >> This allows us to use irqfd with the in-kernel MPIC. > > [snip] >> diff --git a/arch/powerpc/kvm/mpic.c b/arch/powerpc/kvm/mpic.c >> index 10bc08a..d137df8 100644 >> --- a/arch/powerpc/kvm/mpic.c >> +++ b/arch/powerpc/kvm/mpic.c > [snip] >> +int kvm_set_msi(struct kvm_kernel_irq_routing_entry *e, >> + struct kvm *kvm, int irq_source_id, int level, bool line_status) > [snip] >> +int kvm_set_routing_entry(struct kvm_irq_routing_table *rt, >> + struct kvm_kernel_irq_routing_entry *e, >> + const struct kvm_irq_routing_entry *ue) > > How do you see this working once we have more than one interrupt > controller emulation in the kernel? Presumably these two will have to > move out to a common file, rather than being in mpic.c, but then the > question is how do we know which interrupt controller to send the GSI > to? Were you thinking we would have a restriction that you can only > instantiate one interrupt controller of any type? Or were you > thinking we would have an enum for kvm_irq_routing_irqchip::irqchip? > In that case how would we handle MSIs? In a first version of having 2 interrupt controllers, I'd make them mutually exclusive in Kconfig. That way each interrupt controller implements these functions itself. Later we can sit down and generalize this support. Then we would need to have a mapping table which irqchip type each irqchip number is and call the respective functions. But the use for that is so incredibly slim and the user space API would still be the same, that I don't think we need to worry about it today. Alex -- 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
