Re: in-kernel interrupt controller steering

[Gleb Natapov <gleb@redhat.com>]

On Mon, Mar 04, 2013 at 11:20:47PM +0100, 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.
> 
> 
> Alex
> 
Great! Thank you guys for collaborating on this.

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

> 
> 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).
> 
Sounds fine. MSI goes through KVM_SIGNAL_MSI?

> 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.
> 
That's internal implementation detail, so less important to set in stone.

> 
> 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.
> 
What's the difference? The only difference I see is that for migration
you need to make all internal state accessible, for debug this is not
necessary, but since proposed API access each bit of a state one at a time
debug interface should be extensible to become migration interface just
by adding accessible state, no?

> 
> 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.
> 
Do you mean control that retrieves the whole device state in one ioctl
call? Yes, we do not need it.

> 
> 6) The device attribute API will keep read and write (get / set) accessors.
> 
> There is no specific need for a generic "command" ioctl.
That depends on how people will use get/set accessors :)
Since for interrupt injection normal irqchip ioctl will be used we can
probably skip adding "command" ioctl now.

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

--
			Gleb.