Re: [Draft E] Xen on ARM vITS Handling

[Julien Grall <julien.grall@citrix.com>]

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