On 21 July 2012 13:35, Jan Kiszka <jan.kis...@web.de> wrote: > On 2012-07-21 14:17, Peter Maydell wrote: >> 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. > > I bet you ignored MSI so far. Physical IRQ lines are just a part of the > whole picture. How are MSIs delivered on the systems you want to add?
You're using random acronyms without defining them again. It looks as if MSI is a PCI specific term. That would seem to me to fall under the heading of "routing across a board model" which we can't do anyway, because you have no idea how this all wired up, it will depend on the details of the SoC and the PCI controller. (As it happens the initial board model doesn't have PCI support; most ARM boards don't.) I'm not entirely sure we want to have "in kernel random SoC-specific PCI controller"... [Point taken that thought is required here, though.] >>> 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. > > As I said before: "GSI" needs to be read as "physical or virtual IRQ > line". The virtual ones can be of any source you define, irqfd is just one. What's a virtual irq line in this context? We're modelling a physical bit of hardware which has N interrupt lines, so I'm not sure what a virtual irq line would be or how it would appear to the guest... -- PMM -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
