[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Draft E] Xen on ARM vITS Handling
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |