Re: in-kernel interrupt controller steering

[Gleb Natapov <gleb@redhat.com>]

On Wed, Mar 06, 2013 at 12:46:52PM +0100, Alexander Graf wrote:
> 
> On 06.03.2013, at 12:44, Paolo Bonzini wrote:
> 
> > 
> >>>> 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?
> > 
> > Nothing is insurmountable.  However, forcing a particular order
> > of device creation is not very nice on userspace.  If the hypervisor
> > wants to do that, it can do userspace the favor of keeping the id
> > in kernel.  :)
> > 
> >>> Perhaps it's just a problem of naming, and KVM_CREATE_DEVICE is simply
> >>> not the right name for the interface.  Once both KVM_CREATE_IRQCHIP_ARGS
> >>> and KVM_CREATE_DEVICE are added, it really will not create the
> >>> device anymore.
> >>> Devices will be created by KVM_CREATE_IRQCHIP_ARGS, and possibly by
> >>> KVM_CREATE_VCPU.  KVM_CREATE_DEVICE is really only returning an id.
> >>> 
> >>> So we can have this instead:
> >>> - KVM_CREATE_IRQCHIP_ARGS becomes KVM_SET_IRQCHIP_TYPE (and "none"
> >>> can be a valid irqchip type).
> >>> 
> >>> - KVM_CREATE_DEVICE becomes KVM_GET_IRQCHIP_DEVICE, and you pass it
> >>> a device type and possibly a VCPU number.
> >>> 
> >>> It's mostly about names, but one important property is that
> >>> KVM_GET_IRQCHIP_DEVICE can be called at any time and, in fact,
> >>> multiple times.  Gleb, do you like this more?
> >> 
> >> If you put it like this it sounds better (well you've just stashed
> >> the handle in kernel for QEMU convenience :)), but you've made the
> >> interface irqchips specific again and this is what we are trying to avoid.
> > 
> > Yes, KVM_GET_IRQCHIP_DEVICE is specific to irqchips because (following
> > the model of x86) the irqchip type is chosen before creating VCPUs.
> > I don't see an alternative unless we stop having irqchip as an
> > all-or-nothing choice.
> > 
> > I'm not saying KVM_CREATE_DEVICE is a bad interface, but I'm not
> > sure it is really what is needed in this case.  KVM_CREATE_DEVICE
> > would be perfect as a replacement for KVM_CREATE_PIT2, for example.
> > But in this case creating a device is not what we're really doing;
> > the creation is done magically by the hypervisor by virtue of
> > the previous KVM_CREATE_IRQCHIP_ARGS.
> 
> No, it's not and it shouldn't be. To speak in x86 terms:
> 
>   KVM_SET_IRQCHIP_TYPE spawns LAPICs (indirectly, they only get spawned on vcpu creation)
>   KVM_CREATE_DEVICE spawns IOAPICs.
> 
> 
Agree. Lumping up in-kernel LAPIC and IRQCHIPS under one in-kernel
irqchip umbrella was a mistake on x86. The one we should not force on
others.

--
			Gleb.