[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.