From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: in-kernel interrupt controller steering Date: Mon, 4 Mar 2013 18:59:16 -0600 Message-ID: <1362445156.16575.9@snotra> References: <9A4D26CC-338A-418B-B2EC-7FCA9B7E99C4@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Transfer-Encoding: 8BIT Cc: "Overall list:Overall" , , Gleb Natapov , Stuart Yoder , Paul Mackerras , Peter Maydell To: Alexander Graf Return-path: In-Reply-To: <9A4D26CC-338A-418B-B2EC-7FCA9B7E99C4@suse.de> (from agraf@suse.de on Mon Mar 4 16:20:47 2013) Content-Disposition: inline Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 03/04/2013 04:20:47 PM, Alexander Graf wrote: > Howdy, > > We just sat down to discuss the proposed XICS and MPIC interfaces and > how we can take bits of each and create an interface that works for > everyone. In this, it feels like we came to some conclusions. Some of > which we already reached earlier, but forgot in between :). > > I hope I didn't forget too many pieces. Scott, Paul and Stuart, > please add whatever you find missing in here. It looks about right. > 1) We need to set the generic interrupt type of the system before we > create vcpus. > > This is a new ioctl that sets the overall system interrupt controller > type to a specific model. This used so that when we create vcpus, we > can create the appended "local interrupt controller" state without > the actual interrupt controller device available yet. It is also used > later to switch between interrupt controller implementations. > > This interrupt type is write once and frozen after the first vcpu got > created. Who is going to write up this patch? > 2) Interrupt controllers (XICS / MPIC) get created by the device > create api > > Getting and setting state of an interrupt controller also happens > through this. Getting and setting state from vcpus happens through > ONE_REG. Injecting interrupt happens through the normal irqchip ioctl > (we probably need to encode the target device id in there somehow). > > This fits in nicely with a model where the interrupt controller is a > proper QOM device in QEMU, since we can create it long after vcpus > have been created. > > > 3) We open code interrupt controller distinction > > There is no need for function pointers. We just switch() based on the > type that gets set in the initial ioctl to determine which code to > call. The retrieval of the irq type happens through a static inline > function in a header that can return a constant number for > configurations that don't support multiple in-kernel irqchips. > > > 4) The device attribute API has separate groups that target different > use cases > > Paul needs live migration, so he will implement device attributes > that enable him to do live migration. > Scott doesn't implement live migration, so his MPIC attribute groups > are solely for debugging purposes today. > > > 5) There is no need for atomic device control accessors today. > > Live migration happens with vcpus stopped, so we don't need to be > atomic in the kernel <-> user space interface. > > > 6) The device attribute API will keep read and write (get / set) > accessors. > > There is no specific need for a generic "command" ioctl. Gleb, is this OK? A bidirectional command accessor could be added later if a need arises. Will attributes still be renamed to "commands", even if the get/set approach is retained? > 7) Interrupt line connections to vcpus are implicit > > We don't explicitly mark which in-kernel irqchip interrupt line goes > to which vcpu. This is done implicitly. If we see a need for it, we > create a new irqchip device type that allows us to explicitly > configure vcpu connections. Are there any changes needed to the device control api patch (just patch 1/6, not the rest of the patchset), besides Christoffer's request to tone down one of the comments, and whatever the response is to the questions in #6? Should we add a "size" field in kvm_device, both for error checking and to assist tools such as strace? -Scott