Re: [RFC PATCH 0/4] ARM: KVM: Enable the ioeventfd capability of KVM on ARM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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
- the notion of per-CPU interrupts (effectively 16 interrupts banked per
CPU, sharing the same namespace).

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?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm




[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux