On Thu, Apr 10, 2014 at 12:51 PM, Peter Maydell
<peter.maydell@xxxxxxxxxx> wrote:
>
> On 10 April 2014 09:58, Antonios Motakis
> <a.motakis@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> > 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.
>
> I think you should propose a concrete API and give examples
> of how userspace would be using it; these abstract discussions
> aren't really coming together in my head. Can the kernel
> just set up the initial routing mapping as 1:1 so userspace
> can ignore the pointless extra level of indirection?
>
Yes, this is what the user gets by default. Unless KVM_SET_GSI_ROUTING
is used, userspace should not be able to tell the difference.
KVM_IRQ_LINE as used to inject an IRQ, and based on the provided irq
field the right VGIC pin will be stimulated. The mapping of the irq
field to a VGIC pin would be as it is already documented today:
> bits: | 31 ... 24 | 23 ... 16 | 15 ... 0 |
> field: | irq_type | vcpu_index | irq_id |
>
> The irq_type field has the following values:
> - irq_type[0]: out-of-kernel GIC: irq_id 0 is IRQ, irq_id 1 is FIQ
> - irq_type[1]: in-kernel GIC: SPI, irq_id between 32 and 1019 (incl.)
> (the vcpu_index field is ignored)
> - irq_type[2]: in-kernel GIC: PPI, irq_id between 16 and 31 (incl.)
This should be still valid, by default. The only thing that routing
adds, is the capability to use KVM_SET_GSI_ROUTING to change this
mapping to something else (and towards the pins of multiple IRQ chips,
if that need comes up).
Though the part that is of interest to IRQFDs is not the new API to
change the routing. The neat point is that we get an abstraction in
the kernel that allows us to interact with the IRQ chip without having
to deal with the semantics of how that IRQ should be interpreted on
that platform, and the IRQFD code makes use of that.
With KVM_SET_GSI_ROUTING one can provide an array of struct
kvm_irq_routing_entry entries:
struct kvm_irq_routing_entry {
__u32 gsi;
__u32 type;
__u32 flags;
__u32 pad;
union {
struct kvm_irq_routing_irqchip irqchip;
struct kvm_irq_routing_msi msi;
__u32 pad[8];
} u;
};
struct kvm_irq_routing_irqchip {
__u32 irqchip;
__u32 pin;
};
struct kvm_irq_routing_msi {
__u32 address_lo;
__u32 address_hi;
__u32 data;
__u32 pad;
};
__u32 gsi is the global interrupt that we want to match to an IRQ pin.
We map this to an __u32 irqchip and __u32 pin.
For VGIC we just need to define what pins we will expose. For VGICv2
that would be 8 CPUs times 16 PPIs plus the SPIs.
Another difference from other platforms is that we would accept to
reroute only based on the 24 least significant bits; the 8 most
significant bits we already have defined that we need to distinguish
between in kernel and out of kernel IRQs. We would only support
routing for the in-kernel GIC. Asking to reroute an out of kernel GIC,
should return an error to userspace.
Antonios
>
> thanks
> -- PMM
--
Antonios Motakis
Virtual Open Systems
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
