[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: ignoreWhy? 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |