On 21 July 2012 12:08, Jan Kiszka <jan.kiszka@xxxxxx> wrote: > On 2012-07-21 12:53, Peter Maydell wrote: >> This is still sounding like "there is an extra feature which you should >> probably implement at some point and should certainly design with the >> intention of supporting", not "you cannot have an irqchip without irqfds". >> >> Therefore QEMU code which cares about irqfds should be doing >> checks for irqfd functionality, not "is there an in kernel >> irqchip". > > Defining some kvm_irqfd_available() is one thing. Ignoring irqfd "for > now" while introducing in-kernel irqchip is another, less wise decision. You still haven't really explained why we can't just ignore irqfd for now. I don't see how it would particularly affect the design of the kernel implementation very much, and the userspace interface seems to just be an extra ioctl. > Once you support the backend (KVM_SET_GSI_ROUTING + KVM_IRQ_LINE), > adding irqfd is in fact simple. I don't really understand where KVM_SET_GSI_ROUTING comes into this -- the documentation is a bit opaque. It says "Sets the GSI routing table entries" but it doesn't define what a GSI is or what we're routing to where. Googling suggests GSI is an APIC specific term so it doesn't sound like it's relevant for non-x86. I'm not sure what KVM_IRQ_LINE has to do with it either -- this is just the standard interrupt injection ioctl. KVM ARM supports this whether there's an in-kernel irqchip or not. -- PMM -- 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
