Re: [Draft F] Xen on ARM vITS Handling

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

On Fri, 2015-06-12 at 14:07 +0530, Vijay Kilari wrote:

Please could you trim your quotes to only include the bit you are
referring to. Otherwise there is a high chance I will miss a one line
comment in the middle of the thousand lines of quoted matter.

> > The `GITS_BASER0` will be setup to request sufficient memory for a
> > device table consisting of entries of:
> >
> >     struct vdevice_table {
> >         uint64_t vitt_ipa;
> >         uint32_t vitt_size;
> >         uint32_t padding;
> >     };
> 
>       How about adding valid bit to know if the entry is valid or not?

I suggest to use vitt_ipa == INVALID_PADDR to signal this rather than
using another bit.

> > ## Handling of unrouted/spurious LPIs
> >
> > Since there is no 1:1 link between a `vLPI` and `pLPI` enabling and
> > disabling of phyiscal LPIs cannot be driven from the state of an
> > associated vLPI.
> >
> > Each `pLPI` is routed and enabled during device assignment, therefore
> > it is possible to receive a physical LPI which has yet to be routed
> > (via a `vITS`) to a `vLPI`.
> 
> Why do we need to enable LPIs during device assignment?
> Can't we do it only on LPI configuration update, which is trapped in
> Xen as mentioned in 7.8? ( ## Enabling and disabling LPIs)

Quoting the first sentence/paragraph of this section:
        Since there is no 1:1 link between a `vLPI` and `pLPI` enabling
        and disabling of phyiscal LPIs cannot be driven from the state
        of an associated vLPI.

To expand on that: The vITT can map multiple (vDevice,vEvent) pairs to
the same LPI, and each of those (vDevice,vEvent) pairs is related to a
different (pDevice,pEvent) which in turn has a unique pLPI associated
with it. Thus a vLPI can be associated with more than one pLPI.

Enumerating all pLPIs associated with a given vLPI would be expensive (a
complete walk of the vITT).

In addition if it were possible to do so we would also need to manage
enabling/disabling the pLPI in several other places that in vPLI cfg
traps, specifically MAPC and MAPD at least.

So pLPIs must be routed at device assignment time because in the vLPI
configuration table trap there is no mapping back to a single pLPI.

Ian.