Re: [Xen-devel] [Draft E] Xen on ARM vITS Handling

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-06-10 at 10:40 -0400, Julien Grall wrote:
> > ## Virtual LPI injection
> >
> > As discussed above the `vgic_vcpu_inject_irq` functionality will need
> > to be extended to cover this new case, most likely via a new
> > `vgic_vcpu_inject_lpi` frontend function. `vgic_vcpu_inject_irq` will
> > also require some refactoring to allow the priority to be passed in
> > from the caller (since `LPI` proprity comes from the `LPI` CFG table,
> > while `SPI` and `PPI` priority is configured via other means).
> >
> > `vgic_vcpu_inject_lpi` receives a `struct domain *` and a virtual
> > interrupt number (corresponding to a vLPI) and needs to figure out
> > which vcpu this should map to.
> >
> > To do this it must look up the Collection ID associated (via the vITS)
> > with that LPI.
> >
> > Proposal: Add a new `its_device` field to `struct irq_guest`, a
> > pointer to the associated `struct its_device`. The existing `struct
> > irq_guest.virq` field contains the event ID (perhaps use a `union`
> > to give a more appropriate name) and _not_ the virtual LPI. Injection
> > then consists of:
> >
> >          d = irq_guest->domain
> >          virq = irq_guest->virq
> >          its_device = irq_guest->its_device
> >
> >          get_vitt_entry(d, its_device->virt_device_id, virq, &vitt)
> >          vcpu = d->its_collections[vitt.collection]
> >
> >          if !is_valid_lpi(vitt.vlpi): error
> >
> >          get_vlpi_cfg(d, vitt.vlpi, &cfg)
> >          if !cfg.enabled: ignore
> 
> Why? If you ignore it, it won't be possible anymore to inject the same 
> LPI to the guest when it's re-enabled.
> 
> This is a valid use case and can happen if you decouple the pLPI 
> configuration and vLPI configuration or because the value is not yet 
> replicate. AFAIU, you are using the latter in this spec.

Should we mark it as pending somewhere then? We can't actually inject it
for sure, since it is masked.

This would then re-require us to trap writes to the cfg page to allow us
to reenable, which also makes sense.

So the only question is how to record the pending but not injected bit
and to consider any other implications -- such as on SET/CLR_LPIPENDR.



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