On Mon, May 5, 2014 at 5:07 PM, Christoffer Dall
<christoffer.dall@xxxxxxxxxx> wrote:
> On Fri, May 02, 2014 at 08:10:43PM +0200, Antonios Motakis wrote:
>> A potential and straightforward way to augment the KVM_SET_GSI_ROUTING API
>> for ARM/VGIC:
>>
>> New capability: KVM_CAP_IRQ_ROUTING_PPI
>>
>> In addition to the existing routing entry types:
>> /* gsi routing entry types */
>> #define KVM_IRQ_ROUTING_IRQCHIP 1
>> #define KVM_IRQ_ROUTING_MSI 2
>>
>> Add new routing entry type:
>> #define KVM_IRQ_ROUTING_IRQCHIP_PPI 3
>>
>> In the kvm_irq_routing entry struct add an entry for the new union case:
>> struct kvm_irq_routing_entry {
>> __u32 gsi;
>> __u32 type;
>> __u32 flags;
>> __u32 pad;
>> union {
>> struct kvm_irq_routing_irqchip irqchip;
>> struct kvm_irq_routing_irqchip_ppi irqchip_ppi;
>> struct kvm_irq_routing_msi msi;
>> __u32 pad[8];
>> } u;
>> };
>>
>> The new structure may look like this:
>> struct kvm_irq_routing_irqchip {
>> __u32 irqchip;
>> __u32 vcpu;
>> __u32 pin;
>> };
>>
>>
>> SPIs would be set the usual way via the KVM_IRQ_ROUTING_IRQCHIP type.
>> PPIs would be set using the new KVM_IRQ_ROUTING_IRQCHIP_PPI type, and the
>> target VCPU may be specified via __u32 vcpu.
>>
>> The __u32 vcpu variable would be interpreted as is currently done with
>> KVM_IRQ_LINE on ARM: via kvm_get_vcpu(kvm, vcpu_idx).
>>
>> This way more than 256 VCPUs may be added to a system without breaking
>> KVM_IRQ_LINE; it suffices to create new routing tables for the VGIC (the
>> default ones will still map to only 256 VCPUs).
>>
>>
>
> I am getting a little lost in the problem you're trying to solve here.
> Is this only to solve the PPI injection issue since that information is
> currently lacking from the existing interface (unless we abuse some
> other fields?)
Yes, if we want to support PPI pins with more than 256 CPUs, then
abusing the existing interface is not enough.
My original idea was to abuse the irqchip.pin field of
KVM_SET_GSI_ROUTING the same way it is "abused" today by KVM_IRQ_LINE.
However Marc pointed out that we will support more than 256 CPUs in
the future, so encoding 8 bits for the target CPU in the existing
interface will not suffice.
>
> The last comment in the thread was about limited number space and GICv3,
> but this seems unrelated. (Perhaps the top-posting confused me, but it
The limited number space is about the target pins of the VGIC, which
is as many as the target CPUs times PPIs, plus all the SPIs that
follow.
On x86 the irqchip.pin field maps to 2^32 pins, but they are all
global (SPI equivalent). If we map this 2^32 space to both SPIs and
PPIs then we need to significantly reduce the target vCPUs and pins we
can support per vCPU (as is done in KVM_IRQ_LINE - 8 bits used to
encode the target vCPU).
This API proposal was targeted to address that. I think if this won't
be addressed from the start, then we will be stuck with a maximum of
256 vCPUs for ever.
> feels like this suggestion would be easier to digest in an RFC patch
> instead of on this thread.).
Sorry for the top-post. An RFC patch is our intention behind this
discussion. In my opinion implementing IRQ routing is the way to go
for proper irqfd support, but I hope on some kind of agreement that
this would be the acceptable direction for KVM/VGIC :)
--
Antonios Motakis
Virtual Open Systems
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
