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

[Julien Grall <julien.grall@xxxxxxxxxx>]

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.
> 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?
Regards,

--
Julien Grall

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