On 10/18/2012 03:49 PM, Alexander Graf wrote: > > On 18.10.2012, at 15:48, Christoffer Dall wrote: > >> On Wed, Oct 17, 2012 at 7:58 PM, Benjamin Herrenschmidt >> <benh@xxxxxxxxxxxxxxxxxxx> 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? vcpu->requests is checked on each entry. -- error compiling committee.c: too many arguments to function -- 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
