Re: [Draft D] Xen on ARM vITS Handling

[Ian Campbell <ian.campbell@citrix.com>]

On Fri, 2015-06-05 at 22:41 +0530, Vijay Kilari wrote:
> On Fri, Jun 5, 2015 at 10:08 PM, Ian Campbell <ian.campbell@citrix.com> wrote:
> > On Fri, 2015-06-05 at 21:25 +0530, Vijay Kilari wrote:
> >> Let xen mark those phantom devices added using MAPD as dummy and
> >> just emulate and does not translate ITS commands for these devices.
> >
> > But we think guests might use this mechanism to drive completion
> > (instead of polling), so we have to translate INT commands for such
> > devices, don't we? Otherwise such guests won't work.
> 
>   I propose, for guests that use completion INT, the XEN can inject
> lpi by calling vgic_interrupt_inject instead of ITS HW raising interrupt.

Have you read this draft? It says exactly that.

This draft is significantly different from the one which came before, it
is worth rereading the whole thing since most assumption made based on
draft C will now be invalid.

> >> >> So deviceid of any MAPD command for all the guests should be have been
> >> >> within pre-identified list.
> >> >
> >> > I don't think that is true for a domU, not necessarily for a dom0 given
> >> > that any device id can be used with INT.
> >>
> >>    If the INT command is with valid device (not phantom) then Xen can translate
> >> and send to ITS hardware
> >
> > That is not what this design says, Xen will translate and call
> > vgic_interrupt_inject, which doesn't go via the hardware ITS at all,
> > since it doesn't need to.
> 
> I mean, For valid devices, LPI interrupt will be raised when ITS hw
> process INT command.
> from there interrupt handler will inject to domain
> 
> For phantom devices, Xen will inject to directly to domain on seeing
> INT command.
> (we have to ensure that all ITS commands are processed before
> injecting INT to domain)

The design says to use vgic_interrupt_inject for INT commands on any
device, whether phantom or real. It makes no distinction, because it
doesn't need to.

> > [...]
> >> Sorry. I correct it as "So effectively no physical commands are sent
> >> to ITS hardware that are related to dummy/phantom devices"
> >
> > Remember that in this design the vits doesn't generate any commands to
> > the physical its _at all_ even for real devices. It just calls
> > core/generic APIs.
> 
> OK. you mean pITS driver owns translation and sending ITS commands to HW
> instead of vITS?

No, there is no "translation" in this design.

e.g. the vits sees a command which should enable an interrupt. After
figuring out which plpi corresponds it just calls "enable_irq(plpi)". It
doesn't care what that turns into, core interrupt handling core and the
backend pgic driver will take care of doing what is requested. That same
is true for all commands in this design.

In draft D of this design there is _no_ linkage between vits and pits at
all. It is completely abstracted.

Ian.