On Wed, Oct 17, 2012 at 7:58 PM, Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > On Thu, 2012-10-18 at 09:10 +1100, Paul Mackerras wrote: >> >> With the XICS, there are two types of irqchip: a source controller and >> a presentation controller. There is one presentation controller per >> vcpu and typically one source controller per PCI host bridge (a source >> controller can manage multiple sources). The "buid" above is >> basically an identifier for a source controller. >> >> So with the above, it would be quite easy to add new types and >> arguments for them. > > The only possible issue is that afiak, the ioctl number depends on the > structure size, no ? If it does, then we should add some padding to the > union to leave room for new types. > It sounds overall ok to me, however, Peter Maydell pointed out that QEMU is architected in such a way that creating the IRQ chip happens before QEMU knows how the chip fits with the model it is emulating and therefore lacks bits of information that we require for initializing the irq chip.
Specifically on ARM the information needed is the base address of a hardware peripheral, which is virtualization aware, and is mapped directly into the guest's physical address space. One could argue that's not a concern for designing a good kernel api, but on the other hand, qemu is already quite a large system on its own, and we have to be practical. Another alternative is to just let qemu init the device, later give the base address and check before each execution of the vcpu whether the base address has been set and simply return an error if not. This latter approach just seems horrible and unintuitive to me. Thoughts? -Christoffer -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
