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 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?)

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
feels like this suggestion would be easier to digest in an RFC patch
instead of on this thread.).

-Christoffer
_______________________________________________
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