Re: [PATCH v8 00/27] arm64: Dom0 ITS emulation

From: Julien Grall <julien.grall@arm.com>
To: Andre Przywara <andre.przywara@arm.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	Vijay Kilari <vijay.kilari@gmail.com>,
	Shanker Donthineni <shankerd@codeaurora.org>
Subject: Re: [PATCH v8 00/27] arm64: Dom0 ITS emulation
Date: Wed, 12 Apr 2017 15:13:49 +0100	[thread overview]
Message-ID: <61ddee9c-19d4-2cd9-f21f-45984bd95429@arm.com> (raw)
In-Reply-To: <1491957874-31600-1-git-send-email-andre.przywara@arm.com>

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@lists.xen.org
https://lists.xen.org/xen-devel