On 20 August 2012 12:58, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: > On 18/08/12 04:00, Christoffer Dall wrote: >> question: can a peripheral lower the interrupt line again if it's a >> level interrupt and should that then remove the pending state from the >> cpu (move the interrupt away from a vcpu again)? Do we currently >> support this? > > From reading the GIC spec, it looks like deasserting the line removes > the pending state, but not the active state. We will definitely reflect > this change at the distributor level. Yes -- the state machine section of the spec is pretty clear. Pending will go away, but if we're already active that is not cleared until the guest writes to EOIR or DIR. There's also a Note in the documentation of the GICC_IAR giving an example of a level-sensitive interrupt which is deasserted after the OS has been interrupted (by its IRQ line) but before it reads GIC_IAR, in which case we return 1023 for "no interrupt here" (so what happens depends on timing, ie which order the deassert and the sw reading IAR happen in). >>> + * - When the interrupt is EOIed, the maintainance interrupt fires, >>> + * and clears the corresponding bit in irq_active. This allow the >>> + * interrupt line to be sampled again. >>> + */ >>> + >>> +/* Temporary hacks, need to be provided by userspace emulation */ >>> +#define VGIC_DIST_BASE 0x2c001000 >>> +#define VGIC_DIST_SIZE 0x1000 >> >> are we targeting to fix this before a merge into my tree or is it too far ahead? > > I'm not sure we have any plan for this yet. Peter? I think it would be nice to get the VGIC code merged first if it's otherwise OK. It's really only the VGIC base address that we need to tell the kernel about (corresponding to the hardware having config signals for PERIPHBASE) -- the distributor size is fixed by the GIC spec. The difficulty on the qemu side is that the point at which we know the distributor base is rather a long way after we've done the KVM_CREATE_IRQCHIP ioctl. If the kernel implementation is amenable to being told the distributor base address via a separate ioctl somewhat later on that would be preferable... (Also qemu's internal structure is such that the ideal place to call this ioctl doesn't have the info it needs but there's nothing the kernel can do to help with that...) -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
