From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [Draft E] Xen on ARM vITS Handling Date: Wed, 10 Jun 2015 10:52:35 -0400 Message-ID: <55784F33.3030803@citrix.com> References: <1433864565.7108.565.camel@citrix.com> <55784C69.4020500@citrix.com> <1433947542.30003.93.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1433947542.30003.93.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Julien Grall Cc: manish.jaggi@caviumnetworks.com, Julien Grall , Stefano Stabellini , Vijay Kilari , xen-devel List-Id: xen-devel@lists.xenproject.org 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