Re: [PATCH 4/4] pre_init: add ARM implementations

On Wed, Feb 24, 2016 at 03:33:08PM +, Andre Przywara wrote: > The pre_init stub consists of two syscalls mouting the host's FS > via 9pfs and then calling the actual init binary, which can now > use normal dynamic linking. > Based on the x86 code provide an ARM and ARM64 implementation of >

Re: [PATCH 3/4] pre_init: add support for i386 also

On Wed, Feb 24, 2016 at 03:33:07PM +, Andre Przywara wrote: > Currently the pre_init support is provided only for x86_64. Since > having 32-bit x86 supported as well is not far off, just add an > implementation using i386 assembly instructions and the respective > syscall ABI. > >

Re: [PATCH 3/3] virtio: fix endianness check for vhost support

On Tue, Mar 01, 2016 at 04:49:38PM +, Andre Przywara wrote: > Currently we deny any VHOST_* functionality if the architecture > supports guests with different endianness than the host. Most of the > time even on those architectures the endianness of guest and host are > the same, though, so we

Re: [PATCH 2/3] MSI-X: update GSI routing after changed MSI-X configuration

On Tue, Mar 01, 2016 at 04:49:37PM +, Andre Przywara wrote: > When we set up GSI routing to map MSIs to KVM's GSI numbers, we > write the current device's MSI setup into the kernel routing table. > However the device driver in the guest can use PCI configuration space > accesses to change the

Re: [PATCH 1/3] irq: move IRQ routing into irq.c

Hi Andre, On Tue, Mar 01, 2016 at 04:49:36PM +, Andre Przywara wrote: > The current IRQ routing code in x86/irq.c is mostly implementing a > generic KVM interface which other architectures may use too. > Move the code to set up an MSI route into the generic irq.c file and > guard it with the

Re: [PATCH v2 0/8] arm64: Support for systems without AArch32 state

On Thu, Feb 25, 2016 at 09:52:40AM +, Suzuki K Poulose wrote: > This series add checks to make sure that the AArch32 state is > supported before we process the 32bit ID registers. Also > checks the same for COMPAT binary execution. > > (Painfully) applies on top of 4.5-rc5 + [1] + [2]. > >

[RFC v5 10/17] msi: export msi_get_domain_info

We plan to use msi_get_domain_info in VFIO module so let's export it. Signed-off-by: Eric Auger --- v2 -> v3: - remove static implementation in case CONFIG_PCI_MSI_IRQ_DOMAIN is not set --- kernel/irq/msi.c | 1 + 1 file changed, 1 insertion(+) diff --git

[RFC v5 14/17] vfio: allow the user to register reserved iova range for MSI mapping

The user is allowed to [un]register a reserved IOVA range by using the DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA. It provides the base address and the size. This region is stored in the vfio_dma rb tree. At that point the iova range is not mapped to any target

[RFC v5 12/17] msi: IOMMU map the doorbell address when needed

In case the msi is emitted by a device attached to an iommu domain and this iommu domain requires MSI mapping, the msi address (aka doorbell) must be mapped in the IOMMU. Else MSI write transaction will cause a fault. We perform this action at msi message composition time. On any MSI address

[RFC v5 07/17] dma-reserved-iommu: iommu_unmap_reserved

Introduce a new function whose role is to unmap all allocated reserved IOVAs and free the reserved iova domain Signed-off-by: Eric Auger --- v3 -> v4: - previously "iommu/arm-smmu: relinquish reserved resources on domain deletion" ---

[RFC v5 17/17] vfio/type1: return MSI mapping requirements with VFIO_IOMMU_GET_INFO

This patch allows the user-space to know whether MSI addresses need to be mapped in the IOMMU. The user-space uses VFIO_IOMMU_GET_INFO ioctl and IOMMU_INFO_REQUIRE_MSI_MAP gets set if they need to. Also the number of IOMMU pages requested to map those is returned in msi_iova_pages field.

[RFC v5 16/17] iommu/arm-smmu: do not advertise IOMMU_CAP_INTR_REMAP

Do not advertise IOMMU_CAP_INTR_REMAP for arm-smmu. Indeed the irq_remapping capability is abstracted on irqchip side for ARM as opposed to Intel IOMMU featuring IRQ remapping HW. So to check IRQ remapping capability, the msi domain needs to be checked instead. This commit needs to be applied

[RFC v5 00/17] KVM PCIe/MSI passthrough on ARM/ARM64

This series addresses KVM PCIe passthrough with MSI enabled on ARM/ARM64. It pursues the efforts done on [1], [2], [3]. It also aims at covering the same need on PowerPC platforms although the same kind of integration should be carried out. On x86 all accesses to the 1MB PA region [FEE0_h -

[RFC v5 08/17] msi: Add a new MSI_FLAG_IRQ_REMAPPING flag

Let's introduce a new msi_domain_info flag value, MSI_FLAG_IRQ_REMAPPING meant to tell the domain supports IRQ REMAPPING, also known as Interrupt Translation Service. On Intel HW this IRQ remapping capability is abstracted on IOMMU side while on ARM it is abstracted on MSI controller side. This

[RFC v5 05/17] dma-reserved-iommu: reserved binding rb-tree and helpers

we will need to track which host physical addresses are mapped to reserved IOVA. In that prospect we introduce a new RB tree indexed by physical address. This RB tree only is used for reserved IOVA bindings. It is expected this RB tree will contain very few bindings. Those generally correspond to

[RFC v5 06/17] dma-reserved-iommu: iommu_get/put_single_reserved

This patch introduces iommu_get/put_single_reserved. iommu_get_single_reserved allows to allocate a new reserved iova page and map it onto the physical page that contains a given physical address. Page size is the IOMMU page one. It is the responsability of the system integrator to make sure the

[RFC v5 09/17] irqchip/gic-v3-its: ITS advertises MSI_FLAG_IRQ_REMAPPING

The ITS is the first ARM MSI controller advertising the new MSI_FLAG_IRQ_REMAPPING flag. It does so because it supports interrupt translation service. This HW support offers isolation of MSIs, feature used when using KVM device passthrough. Signed-off-by: Eric Auger ---

[RFC v5 03/17] iommu: introduce a reserved iova cookie

This patch introduces some new fields in the iommu_domain struct, dedicated to reserved iova management. In a similar way as DMA mapping IOVA window, we need to store information related to a reserved IOVA window. The reserved_iova_cookie will store the reserved iova_domain handle. An RB tree

[RFC v5 13/17] vfio: introduce VFIO_IOVA_RESERVED vfio_dma type

We introduce a vfio_dma type since we will need to discriminate legacy vfio_dma's from new reserved ones. Since those latter are not mapped at registration, some treatments need to be reworked: removal, replay. Currently they are unplugged. In subsequent patches they will be reworked.

[RFC v5 11/17] msi: msi_compose wrapper

Currently the MSI message is composed by directly calling irq_chip_compose_msi_msg and erased by setting the memory to zero. On some platforms, we will need to complexify this composition to properly handle MSI emission through IOMMU. Also we will need to track when the MSI message is erased. We

[RFC v5 04/17] dma-reserved-iommu: alloc/free_reserved_iova_domain

Introduce alloc/free_reserved_iova_domain in the IOMMU API. alloc_reserved_iova_domain initializes an iova domain at a given iova base address and with a given size. This iova domain will be used to allocate iova within that window. Those IOVAs will be reserved for special purpose, typically MSI

[PATCH 2/3] MSI-X: update GSI routing after changed MSI-X configuration

When we set up GSI routing to map MSIs to KVM's GSI numbers, we write the current device's MSI setup into the kernel routing table. However the device driver in the guest can use PCI configuration space accesses to change the MSI configuration (address and/or payload data). Whenever this happens

[PATCH 1/3] irq: move IRQ routing into irq.c

The current IRQ routing code in x86/irq.c is mostly implementing a generic KVM interface which other architectures may use too. Move the code to set up an MSI route into the generic irq.c file and guard it with the KVM_CAP_IRQ_ROUTING capability to return an error if the kernel does not support

[PATCH 3/3] virtio: fix endianness check for vhost support

Currently we deny any VHOST_* functionality if the architecture supports guests with different endianness than the host. Most of the time even on those architectures the endianness of guest and host are the same, though, so we are denying the glory of VHOST needlessly. Switch from compile time

Re: [PATCH] arm64: KVM: Move kvm_call_hyp back to its original localtion

On Tue, Mar 01, 2016 at 01:12:44PM +, Marc Zyngier wrote: > In order to reduce the risk of a bad merge, let's move the new > kvm_call_hyp back to its original location in the file. This has > zero impact from a code point of view. > > Signed-off-by: Marc Zyngier > --- >

Re: [PATCH] arm64: KVM: Move kvm_call_hyp back to its original localtion

On 1 March 2016 at 14:12, Marc Zyngier wrote: > In order to reduce the risk of a bad merge, let's move the new > kvm_call_hyp back to its original location in the file. This has > zero impact from a code point of view. > > Signed-off-by: Marc Zyngier

[PATCH] arm64: KVM: Move kvm_call_hyp back to its original localtion

In order to reduce the risk of a bad merge, let's move the new kvm_call_hyp back to its original location in the file. This has zero impact from a code point of view. Signed-off-by: Marc Zyngier --- Catalin, Would you mind merging this on top of arm64/for-next/core? I just