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" <gleb@xxxxxxxxxx>
>>> A: "Paolo Bonzini" <pbonzini@xxxxxxxxxx>
>>> Cc: "Alexander Graf" <agraf@xxxxxxx>, kvm@xxxxxxxxxxxxxxx, kvm-ppc@xxxxxxxxxxxxxxx, "Stuart Yoder"
>>> <stuart.yoder@xxxxxxxxxxxxx>, "Scott Wood" <scottwood@xxxxxxxxxxxxx>, "Paul Mackerras" <paulus@xxxxxxxxx>, "Peter
>>> Maydell" <peter.maydell@xxxxxxxxxx>
>>> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
