[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v8 00/27] arm64: Dom0 ITS emulation
On 12/04/17 01:44, Andre Przywara wrote: Hi, this is a reworked version of the second part of the ITS emulation series, where the first part has been merged already. It extends the concept of letting Xen deal with irq_to_pending() potentially returning NULL, by making sure the retrieval and usage of the pending_irq pointer is always happening under the VCPU VGIC lock (patch 02 and 03). This allows us to free the memory for the pending_irqs when a device gets unmapped. Patch 20 contains a relatively easy solution to some LPI unmap/map corner case (DISCARD;MAPTI sequence using the same virtual LPI number while the VLPI is pending in some LR). On top of these changes I addressed the remaining comments from v5 and v6. For a detailed changelog see below. Cheers, Andre ---------------------------------- This series adds support for emulation of an ARM GICv3 ITS interrupt controller. For hardware which relies on the ITS to provide interrupts for its peripherals this code is needed to get a machine booted into Dom0 at all. ITS emulation for DomUs is only really useful with PCI passthrough, which is not yet available for ARM. It is expected that this feature will be co-developed with the ITS DomU code. However this code drop here considered DomU emulation already, to keep later architectural changes to a minimum. This is technical preview version to allow early testing of the feature. Things not (properly) addressed in this release: - The MOVALL command is not emulated. In our case there is really nothing to do here. We might need to revisit this in the future for DomU support. - The INVALL command might need some rework to be more efficient. Currently we iterate over all mapped LPIs, which might take a bit longer. - Indirect tables are not supported. This affects both the host and the virtual side. - The command queue locking is currently suboptimal and should be made more fine-grained in the future, if possible. - We don't move the LPIs on the host to the pCPU where the target VCPU is currently running on. Doing so would involve sending ITS commands to the host. We should investigate whether this is feasible during scheduling. - MOVI doesn't move pending IRQs. - We need to properly investigate the possible interaction when devices get removed. This requires to properly clean up and remove any associated resources like pending or in-flight LPIs, for instance. It looks like you missed some items not (properly) addressed: - SMMU support with ITS - Prevent interrupt storm - DomU support * Export nr_lpis through arch_domain_config* Protection of memory provided by the guest (e.g Device Table, Collection Table...) Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |