On 2012-10-18 15:48, Christoffer Dall wrote: > 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?
The current irqchip API is like this: KVM_CREATE_IRQCHIP (without any parameters) ... KVM_CREATE_VCPU KVM_SET_IRQCHIP (or the other way around) ... KVM_RUN The arguments you cannot pass via KVM_CREATE_IRQCHIP - which is more like a "Hey, there will be an IRQ chip!" - could be passed via KVM_SET_IRQCHIP (it has 512 bytes space). Provided there are sane configuration defaults, at least after KVM_CREATE_VCPU, KVM_SET_IRQCHIP becomes optional. Then you don't need the a check on KVM_RUN. What do we need in addition to this in any of the non-x86 archs? Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux -- 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
