On 18.10.2012, at 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?
Wasn't there some "sane" field in the vcpu structs that you can hijack to make sure you only ever VCPU_RUN when the VM is complete? Alex -- 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
