On 06.03.2013, at 12:26, Gleb Natapov wrote: > On Wed, Mar 06, 2013 at 05:38:33AM -0500, Paolo Bonzini wrote: >> >> >> ----- Messaggio originale ----- >>> Da: "Gleb Natapov" <g...@redhat.com> >>> A: "Paolo Bonzini" <pbonz...@redhat.com> >>> Cc: "Alexander Graf" <ag...@suse.de>, kvm@vger.kernel.org, >>> kvm-...@vger.kernel.org, "Stuart Yoder" >>> <stuart.yo...@freescale.com>, "Scott Wood" <scottw...@freescale.com>, "Paul >>> Mackerras" <pau...@samba.org>, "Peter >>> Maydell" <peter.mayd...@linaro.org> >>> Inviato: Mercoledì, 6 marzo 2013 10:58:35 >>> Oggetto: Re: in-kernel interrupt controller steering >>> >>> On Wed, Mar 06, 2013 at 10:40:18AM +0100, Paolo Bonzini wrote: >>>> Il 05/03/2013 16:25, Gleb Natapov ha scritto: >>>>>> 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. >>>>> >>>>> Why explicit ioctl is needed? Why not require specific irqchip to >>>>> be >>>>> created before first vcpu. The device created determines system >>>>> interrupt >>>>> controller type. >>>> >>>> QEMU creates CPUs before devices, and CPUs need to know what kind of >>>> local interrupt controller to create. Similar to how in-kernel LAPIC >>>> state is created long before the userspace device that proxies the >>>> LAPIC. >>> >>> So what is the difference between calling this special ioctl before >>> creating vcpus and calling create device ioctl instead and create >>> QEMU proxy device at whatever point in time QEMU wants to create it? >> >> Because you'd have to stash the handle that KVM_CREATE_DEVICE returns >> somewhere, waiting for the QEMU device to be created. >> > OK, we try not to add interfaces for one userspace convenience though. > Is this such insurmountable problem for QEMU?
Please go ahead and try to describe an interface the way you envision it. It needs to fulfill the following criteria: * different machine models have different interrupt controller types * we need to be able to fetch information from interrupt controllers, this should be as flexible as possible because we don't know all future state we want to synchronize today * user space creates its virtual representation of an interrupt controller after the vcpus got created * user space needs a token to an interrupt controller, so that we have the possibility to add a second in-kernel irqchip if the need arises What the current interface does is: SET_IRQCHIP_TYPE: * declare CPUs as listeners to a specific irqchip bus * set the path that interrupt injection takes (this could probably be changed to dynamic lookups though, based on device tokens) CREATE_DEVICE: * spawn one or multiple in-kernel irqchip devices that hook up to CPUs using the irqchip bus * tell user space a token to access this irqchip I really don't see why you wouldn't want to have that split. 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