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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-06-10 at 10:52 -0400, Julien Grall wrote:
> 
> On 10/06/2015 10:45, Ian Campbell wrote:
> > 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.
> 
> vgic_vcpu_inject_irq does already the job for you. If the IRQ is not 
> enabled (i.e !GIC_IRQ_GUEST_QUEUED), the IRQ will be queue in the list 
> of inflight irqs of the VCPU.

Oh, good that's simple then.

> > This would then re-require us to trap writes to the cfg page to allow us
> > to reenable, which also makes sense.
> 
> Correct.
> 
> > 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.
> 
> I don't follow you. I though we said that we ignore guest request to 
> clear IRQ?

I said "consider", maybe we don't need to do anything.

Ian.


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