[Xen-devel] [PATCH v2] xen: arm: context switch vtimer PPI state.

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

... instead of artificially masking the timer interrupt in the timer
state and relying on the guest to unmask which it isn't required to
do per the h/w spec, although Linux does, other OSes (FreeRTOS?) needed
changes. Making the vtimer follow the h/w spec is the main driving force
here although it may also enable us to do direct injection in the future
(GIC >=v4). It's also something I wanted to sort out before starting to
think about how to migrate a vtimer.

This series introduces the concept of routing a PPI to the currently
running VCPU and of context switching its state using the GICD I[SC]ACTIVER
registers to save and restore the active state of the interrupt. In the
case of the vtimer this prevents the nested invocations which the current
masking works around.

For edge triggered interrupts we also need to context switch the
pending bit via I[SC]PENDR. Note that for level triggered interrupts
SPENDR sets a latch which is only cleared by ICPENDR (and not by h/w
state changes), therefore we do not want to context switch the pending
state for level PPIs -- instead we rely on the context switch of the
peripheral to restore the correct level.

This is an update of a much older RFC[0]. Lots has changed, the hooks are
now at a different level with more common code (although maybe not as much
as I would like) and lots of refactoring, It also now handles non-1:1
configurations (tested with a patch to forceÂGUEST_TIMER_VIRT_PPI to
something whic didn't match the h/w platform).

I also switched from using struct irq_guest->d (domain) == NULL to signal
this type of interrupt to using desc->state containing both IRQ_GUEST and
IRQ_PER_CPU as the trigger instead as discussed in[1].

I think I've addressed all the comments which remained relevant after the
reworking, although so much has changed I'm not completely sure, sorry if
I've missed anything.

Ian.

[0]Âhttp://lists.xen.org/archives/html/xen-devel/2015-01/msg03161.html
[1]Âhttp://lists.xen.org/archives/html/xen-devel/2015-11/msg00842.html

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel