On 9 January 2013 10:02, Alexander Graf <ag...@suse.de> wrote: > I think we should make thus at least potentially generic. In fact, I wouldn't > even > mind calling it DEV_REG with the same semantics as ONE_REG, just that it also > gets a unique dev id that gets created during in-kernel device creation and > that > it's a vm ioctl.
Well, we might want a DEV_REG, but you might as well just make ONE_REG OK as a VM ioctl, since there's no reason not to have not-per-cpu but not device registers. ONE_REG already supports dividing up the ID space so you can say which device or whatever is being used, because we had things like GIC registers in mind when we put that API together. However, this shouldn't be DEV_REG, because this isn't actually setting state in the irqchip device, it's configuring the kernel's part of the system model [compare wiring up irq routing, which also has a custom ioctl rather than a generic one]. As such it definitely needs to happen only before the VM is actually started and not during VM execution, unlike a DEV_REG which would presumably be generally valid. > That way we wouldn't block our path to create two in-kernel irqchips one day. Er, SET_DEVICE_ADDRESS doesn't block us doing that; that's why it has an ID parameter. The discussion at the KVM forum, as I recall it was basically: (a) some other ppc irqchips also want to set the base address for where their memory mapped registers live, so this isn't a totally ARM specific weirdness (b) we didn't need to tangle up and delay the KVM ARM work with a vague and unspecified desire for general configurability -- 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
