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