On 12/12/2011 06:31 PM, Peter Maydell wrote: > On 11 December 2011 23:01, Jan Kiszka <jan.kiszka@xxxxxx> wrote: > > Enabling in-kernel irqchips usually means "switching worlds". So the > > semantics of these particular IRQ inject interface details may change > > without breaking anything. > > > > However, things might look different if there will be a need to inject > > also the CPU IRQs directly, not only the irqchip inputs. In that case, > > it may make some sense to reserve more space for interrupt types than > > just one bit and use a common encoding scheme. > > I think with an in-kernel GIC model you'd only need to be able to set > one of the (256 including internal-to-the-CPU inputs) GIC input lines; > the GIC itself then connects directly to the vcpu IRQ and FIQ. > > So we could just have different semantics for the ioctl in the 'kernel > GIC model enabled' config, as you suggest. btw, since we use the KVM_IRQ_LINE ioctl, it may make sense to require KVM_CREATE_IRQCHIP. To create a kernel GIC model, just call KVM_CREATE_IRQCHIP with a different parameter. This removes an "except for ARM" from the documentation. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
