On Fri, 26 Feb 2016, Eric Auger wrote:
> +static int msi_map_doorbell(struct iommu_domain *d, struct msi_msg *msg)
> +{
> +#ifdef CONFIG_IOMMU_DMA_RESERVED
> + dma_addr_t iova;
> + phys_addr_t addr;
> + int ret;
> +
> +#ifdef CONFIG_PHYS_ADDR_T_64BIT
> + addr = ((phys_addr_t)(msg->a
On Fri, 26 Feb 2016, Eric Auger wrote:
> 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 capability is abstracted on IOMMU
> side while on ARM it is abstracte
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. User-spac
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
addres
On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted
by the msi controller. vfio_safe_irq_domain allows to check whether
interrupts are "safe" for a given device. They are if the device does
not use MSI or if the device uses MSI and the msi-parent controller
supports IRQ 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 aft
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.
Signed-off-b
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"
---
drivers/iommu/dma-reserved-iommu.c | 27 +
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 capability is abstracted on IOMMU
side while on ARM it is abstracted on MSI controller side.
GICv3 ITS HW is the f
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 ind
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
In case the msi_desc references a device attached to an iommu
domain and this iommu domain requires MSI mapping, the msi
address (aka doorbell) needs to be mapped in the IOMMU. Else any
MSI write transaction will cause a fault.
We perform this action at msi message composition time. We
need to tra
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 a/kernel/irq/msi.c b/kernel/irq/msi.c
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 fr
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 i
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 - FE
Introduce new DOMAIN_ATTR_MSI_MAPPING domain attribute. If supported,
this means the MSI addresses need to be mapped in the IOMMU. ARM SMMUS
and FSL PAMU, at least expose this attribute.
x86 IOMMUs typically don't expose the attribute since on x86, MSI write
transaction addresses always are within
2016-02-26 2:54 GMT-05:00 Christoffer Dall :
> On Thu, Feb 25, 2016 at 12:45:45PM -0500, xu mike wrote:
>> Hi Peter,
>>
>> 2016-02-25 10:30 GMT-05:00 Peter Maydell :
>> >
>> > On 25 February 2016 at 15:17, xu mike wrote:
>> > > I'm a student from the University of Pennsylvania. I want to try KVM o
On 7 December 2015 at 12:29, Pavel Fedin wrote:
> From: Christoffer Dall
>
> Factor out the GICv3-specific documentation into a separate
> documentation file. Add description for how to access distributor,
> redistributor, and CPU interface registers for GICv3 in this new file.
>
> Acked-by: Pet
From: Shannon Zhao
When calling perf_event_create_kernel_counter to create perf_event,
assign a overflow handler. Then when the perf event overflows, set the
corresponding bit of guest PMOVSSET register. If this counter is enabled
and its interrupt is enabled as well, kick the vcpu to sync the
in
On 26 February 2016 at 08:06, Christoffer Dall
wrote:
> On Thu, Feb 25, 2016 at 04:51:51PM +, Peter Maydell wrote:
>> [Typoed the kvmarm list address; sorry... -- PMM]
>>
>> On 25 February 2016 at 12:09, Peter Maydell wrote:
>> > The virt board restricts guests to only 30GB of RAM. This is a
On Wed, Feb 24, 2016 at 10:33:37PM +0800, Shannon Zhao wrote:
> When calling perf_event_create_kernel_counter to create perf_event,
> assign a overflow handler. Then when the perf event overflows, set the
> corresponding bit of guest PMOVSSET register. If this counter is enabled
> and its interrupt
On Thu, Feb 25, 2016 at 04:51:51PM +, Peter Maydell wrote:
> [Typoed the kvmarm list address; sorry... -- PMM]
>
> On 25 February 2016 at 12:09, Peter Maydell wrote:
> > The virt board restricts guests to only 30GB of RAM. This is a
> > hangover from the vexpress-a15 board, and there's inhere
23 matches
Mail list logo
