Re: in-kernel interrupt controller steering

[Paolo Bonzini <pbonzini@redhat.com>]

> > > 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.

Paolo