On Tue, Apr 1, 2014 at 11:30 AM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: > On 31/03/14 18:36, Christoffer Dall wrote: >> On Mon, Mar 31, 2014 at 05:28:06PM +0100, Peter Maydell wrote: >>> On 31 March 2014 17:12, Alexander Graf <agraf@xxxxxxx> wrote: >>>> On 03/31/2014 05:53 PM, Peter Maydell wrote: >>>>> >>>>> On 31 March 2014 16:49, Alexander Graf <agraf@xxxxxxx> wrote: >>>>>> >>>>>> On 03/31/2014 03:53 PM, Peter Maydell wrote: >>>>>>> Er, but we already have a global interrupt index number >>>>>>> for ARM, it's the value you pass to KVM_IRQ_LINE. What >>>>>>> extra does IRQ routing bring to the party? >>>>>> >>>>>> It allows you to have multiple distributors :). And MSI target IDs that >>>>>> you >>>>>> can use for irqfd. >>>>> >>>>> What's a distributor in this context? Why would an MSI >>>>> target ID need to be any different from the ID format >>>>> we're currently using? >>>> >>>> >>>> Because it may contain more information than the number space allows to >>>> cover (target address, data payload). >>> >>> I'm finding this conversation confusing because I think you're >>> assuming more knowledge about MSI and irqfds than I have. >>> What I was hoping to provoke with my initial question was >>> a more detailed explanation of what the API does, when >>> it gets used and what information gets passed around where. >>> >> I am in the same boat as Peter currently, sharing the same hopes. >> >> For example, I don't understand when we already have a way on ARM to >> configure the global number space of IRQs to have CPU affinity (the >> guest CPU does this by programming the emulated distributor; the fact >> that this is currently not completely implemented is besides the point) >> and the fact that we already have PPIs on ARM makes it hard for me to >> understand how "IRQ Routing" adds something missing to this picture, or >> even how it would semantically not conflict. > > Yeah, same here. I think we have a deep disconnect about what the KVM > infrastructure provides/expects, and what the ARM architecture > (including the GIC) provides. > Though in this case, what makes IRQ routing support useful is not any particular feature it enables, but how it is used as a standard interface towards in-kernel IRQ chips for KVM. The eventfd support in KVM makes heavy use of that, so IRQ routing gives us IRQFDs without having to completely butcher all the eventfd and irqfd code. > As Christoffer mentioned above, the GIC (all variants of it) already > gives us: > - a global interrupt space (SPIs, mostly) > - a routing mechanism to deliver interrupts to particular CPUs As far as I understand IRQ routing in this case is meant as a mechanism to deliver interrupts to particular IRQ chip pins. So when creating a guest with multiple IRQ chips, things can be rewired as needed. How each of those pins on the VGIC will be handled, that would probably be essentially unchanged. If this is really of use on ARM, I don't know. > - the notion of per-CPU interrupts (effectively 16 interrupts banked per > CPU, sharing the same namespace). With IRQ routing, each IRQ chip would have 16 extra pins per CPU, plus all the global pins (no need for pins for SGIs). What the current KVM_IRQ_LINE call does, is map the values of the received irq field to pins of a sole GIC. So in a way, the interface has a sort of build in implicit 'IRQ routing'. With IRQ routing this support would be just a default mapping, giving us the ability to change it (and also fit multiple different IRQ chips). > > As for MSIs, there are two cases: > - GICv2m: this is just another signaling method on top on SPIs, hence > using the same routing mechanism (GICD_TARGETR). > - GICv3/4: LPIs can be routed to arbitrary CPUs using the ITS. > > In all cases, what does routing gives us? That's what I'd like to > understand. > > Alex, can you please explain to us dumb ARM people (in very simple > terms, without too many x86 acronyms ;-) what this GSI routing actually > gives us on top of what we already have? In the case of eventfds, IRQ routing is part of a standard way IRQ chips expose themselves internally. The ability to change how KVM_IRQ_LINE irqs map to IRQ chip pins comes as a bonus. > > Thanks, > > M. > -- > Jazz is not dead. It just smells funny... -- Antonios Motakis Virtual Open Systems _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
