On Mon, Feb 18, 2013 at 3:01 PM, Scott Wood <scottw...@freescale.com> wrote: > On 02/18/2013 06:21:59 AM, Gleb Natapov wrote: >> >> Copying Christoffer since ARM has in kernel irq chip too. >> >> On Wed, Feb 13, 2013 at 11:49:15PM -0600, Scott Wood wrote: >> > Currently, devices that are emulated inside KVM are configured in a >> > hardcoded manner based on an assumption that any given architecture >> > only has one way to do it. If there's any need to access device state, >> > it is done through inflexible one-purpose-only IOCTLs (e.g. >> > KVM_GET/SET_LAPIC). Defining new IOCTLs for every little thing is >> > cumbersome and depletes a limited numberspace. >> > >> > This API provides a mechanism to instantiate a device of a certain >> > type, returning an ID that can be used to set/get attributes of the >> > device. Attributes may include configuration parameters (e.g. >> > register base address), device state, operational commands, etc. It >> > is similar to the ONE_REG API, except that it acts on devices rather >> > than vcpus. >> You are not only provide different way to create in kernel irq chip you >> also use an alternate way to trigger interrupt lines. Before going into >> interface specifics lets think about whether it is really worth it? > > > Which "it" do you mean here? > > The ability to set/get attributes is needed. Sorry, but "get or set one > blob of data, up to 512 bytes, for the entire irqchip" is just not good > enough -- assuming you don't want us to start sticking pointers and commands > in *that* data. :-) > > If you mean the way to inject interrupts, it's simpler this way. Why go out > of our way to inject common glue code into a communication path between > hw/kvm/mpic.c in QEMU and arch/powerpc/kvm/mpic.c in KVM? Or rather, why > make that common glue be specific to this one function when we could reuse > the same communication glue used for other things, such as device state? > > And that's just for regular interrupts. MSIs are vastly simpler on MPIC > than what x86 does. > > >> x86 obviously support old way and will have to for some, very long, time. > > > Sure. > > >> ARM vGIC code, that is ready to go upstream, uses old way too. So it will >> be 2 archs against one. > > > I wasn't aware that that's how it worked. :-P > > I was trying to be considerate by not making the entire thing gratuitously > PPC or MPIC specific, as some others seem inclined to do (e.g. see irqfd and > APIC). We already had a discussion on ARM's "set address" ioctl and rather > than extend *that* interface, they preferred to just stick something > ARM-specific in ASAP with the understanding that it would be replaced (or > more accurately, kept around as a thin wrapper around the new stuff) later. > > >> Christoffer do you think the proposed way it >> better for your needs. Are you willing to make vGIC use it? >>
Well it won't improve functionality much from the current hardware point of view, but the proposed interface is superior to what we have now. Adding and coordinating new interfaces is indeed a pain, so a generic interface which is flexible enough to cater for a certain group of needs, is welcome imho. And this does seem to fit the bill. I can imagine that if there's support for a future ARM gic version or if we add in-kernel support for other stuff on ARM, then this interface will be useful, and in fact using the current interface to support two separate, but similar, interrupt controllers could get messy from a user space point of view. I am definitely willing to change to use this interface, the agreement on the KVM_ARM_SET_DEVICE_ADDR ioctl was exactly because of this. I had some nits on the RFC, which I'll send separately. >> Scott, what other devices are you planning to support with this >> interface? > > > At the moment I do not have plans for other devices, though what does it > hurt for the capability to be there? > -- 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
