[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.