On Thu, 6 Oct 2016 14:20:40 -0600
Alex Williamson wrote:
> On Thu, 6 Oct 2016 08:45:31 +
> Eric Auger wrote:
>
> > This patch allows the user-space to retrieve the MSI geometry. The
> > implementation is based on capability chains, now also added to
> > VFIO_IOMMU_GET_INFO.
> >
> > The re
On Thu, 6 Oct 2016 08:45:31 +
Eric Auger wrote:
> This patch allows the user-space to retrieve the MSI geometry. The
> implementation is based on capability chains, now also added to
> VFIO_IOMMU_GET_INFO.
>
> The returned info comprise:
> - whether the MSI IOVA are constrained to a reserve
On Thu, 6 Oct 2016 08:45:29 +
Eric Auger wrote:
> On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted
> by the msi controller.
>
> Since we currently have no way to detect whether the MSI controller is
> upstream or downstream to the IOMMU we rely on the MSI doorbell
On Thu, 6 Oct 2016 08:45:28 +
Eric Auger wrote:
> The user is allowed to register a reserved MSI IOVA range by using the
> DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA.
> This region is stored in the vfio_dma rb tree. At that point the iova
> range is not mapped
On Thu, 6 Oct 2016 08:45:27 +
Eric Auger wrote:
> Before allowing the end-user to create VFIO_IOVA_RESERVED dma slots,
> let's implement the expected behavior for removal and replay.
>
> As opposed to user dma slots, reserved IOVAs are not systematically bound
> to PAs and PAs are not pinne
On Thu, 6 Oct 2016 08:45:26 +
Eric Auger wrote:
> This patch handles the case where a node is encountered, matching
> @start and @size arguments but not matching the @type argument.
> In that case, we need to skip that node and pursue the search in the
> node's leaves. In case @start is infe
On Thu, 6 Oct 2016 08:45:25 +
Eric Auger wrote:
> In our RB-tree we get prepared to insert slots of different types
> (USER and RESERVED). It becomes useful to be able to search for dma
> slots of a specific type or any type.
>
> This patch introduces vfio_find_dma_from_node which starts th
On Thu, 6 Oct 2016 08:45:24 +
Eric Auger wrote:
> We introduce a vfio_dma type since we will need to discriminate
> different types of dma slots:
> - VFIO_IOVA_USER: IOVA region used to map user vaddr
> - VFIO_IOVA_RESERVED_MSI: IOVA region reserved to map MSI doorbells
>
> Signed-off-by: E
On Thu, 6 Oct 2016 08:45:20 +
Eric Auger wrote:
> We introduce a new msi-doorbell API that allows msi controllers
> to allocate and register their doorbells. This is useful when
> those doorbells are likely to be iommu mapped (typically on ARM).
> The VFIO layer will need to gather informati
On Thu, 6 Oct 2016 08:45:19 +
Eric Auger wrote:
> From: Robin Murphy
>
> IOMMU domain users such as VFIO face a similar problem to DMA API ops
> with regard to mapping MSI messages in systems where the MSI write is
> subject to IOMMU translation. With the relevant infrastructure now in
> p
On Thu, 6 Oct 2016 08:45:18 +
Eric Auger wrote:
> On ARM, MSI write transactions also are translated by the smmu.
> Let's report that specificity by setting the iommu_msi_supported
> field to true. A valid aperture window will need to be provided.
>
> Signed-off-by: Eric Auger
>
> ---
> v
On Thu, Sep 29, 2016 at 10:12:31AM +0200, Marek Szyprowski wrote:
> This patch uses recently introduced device links to track the runtime pm
> state of the master's device. This way each SYSMMU controller is runtime
> activated when its master's device is active
instead of?
BTW what is the maste
Hello again,
Tobias Jakobi wrote:
> Hello Marek,
>
> I have applied the new version onto 4.8.0 but I'm seeing this Oops on
> shutdown/reboot. However it only shows up with my non-debug config.
sorry for the false alarm. That Oops on reboot was due to some other
patch I had applied.
With best w
Do not advertise IOMMU_CAP_INTR_REMAP for arm-smmu(-v3). 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 affects platform a
This patch allows the user-space to retrieve the MSI geometry. The
implementation is based on capability chains, now also added to
VFIO_IOMMU_GET_INFO.
The returned info comprise:
- whether the MSI IOVA are constrained to a reserved range (x86 case) and
in the positive, the start/end of the aper
On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted
by the msi controller.
Since we currently have no way to detect whether the MSI controller is
upstream or downstream to the IOMMU we rely on the MSI doorbell information
registered by the interrupt controllers. In case at l
This patch handles the case where a node is encountered, matching
@start and @size arguments but not matching the @type argument.
In that case, we need to skip that node and pursue the search in the
node's leaves. In case @start is inferior to the node's base, we
resume the search on the left leaf.
In our RB-tree we get prepared to insert slots of different types
(USER and RESERVED). It becomes useful to be able to search for dma
slots of a specific type or any type.
This patch introduces vfio_find_dma_from_node which starts the
search from a given node and stops on the first node that match
Before allowing the end-user to create VFIO_IOVA_RESERVED dma slots,
let's implement the expected behavior for removal and replay.
As opposed to user dma slots, reserved IOVAs are not systematically bound
to PAs and PAs are not pinned. VFIO just initializes the IOVA "aperture".
IOVAs are allocated
The user is allowed to register a reserved MSI IOVA range by using the
DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA.
This region is stored in the vfio_dma rb tree. At that point the iova
range is not mapped to any target address yet. The host kernel will use
those iova
We introduce a new msi-doorbell API that allows msi controllers
to allocate and register their doorbells. This is useful when
those doorbells are likely to be iommu mapped (typically on ARM).
The VFIO layer will need to gather information about those doorbells:
whether they are safe (ie. they imple
Following Robin's series [1], addressing MSI IOMMU mapping for devices
attached to a DMA ops domain, quite a lot of changes (and simplifications)
were induced with respect to the v12 iteration:
- msi-iommu API role now is handled at dma-iommu level
- MSI doorbell registration API still is used for
From: Robin Murphy
IOMMU domain users such as VFIO face a similar problem to DMA API ops
with regard to mapping MSI messages in systems where the MSI write is
subject to IOMMU translation. With the relevant infrastructure now in
place for managed DMA domains, it's actually really simple for other
Introduce a new DOMAIN_ATTR_MSI_GEOMETRY domain attribute. It enables
to query the aperture of the IOVA window dedicated to MSIs and
test whether the MSIs must be IOMMU mapped.
x86 IOMMUs will typically expose an MSI aperture matching the 1MB
region [FEE0_h - FEF0_000h] corresponding to the th
msi_doorbell_calc_pages() sum up the number of iommu pages of a given order
requested to map all the registered doorbells. This function will allow
to dimension the intermediate physical address (IPA) aperture requested
to map the MSI doorbells.
Note this requirement cannot be computed at MSI door
Register the GIC V2M global doorbell. The registered information
are used to set up the KVM passthrough use case.
Signed-off-by: Eric Auger
---
v12 -> v13:
- use new msi doorbell registration prototype
- remove iommu protection attributes
- add unregistration in teardown
v11 -> v12:
- use irq_g
This patch registers the ITS global doorbell. Registered information
are needed to set up the KVM passthrough use case.
Signed-off-by: Eric Auger
---
v12 -> v13:
- use new doorbell registration prototype
v11 -> v12:
- use new irq_get_msi_doorbell_info name
- simplify error handling
v10 -> v11:
We introduce a vfio_dma type since we will need to discriminate
different types of dma slots:
- VFIO_IOVA_USER: IOVA region used to map user vaddr
- VFIO_IOVA_RESERVED_MSI: IOVA region reserved to map MSI doorbells
Signed-off-by: Eric Auger
---
v9 -> v10:
- renamed VFIO_IOVA_RESERVED into VFIO_I
On ARM, MSI write transactions also are translated by the smmu.
Let's report that specificity by setting the iommu_msi_supported
field to true. A valid aperture window will need to be provided.
Signed-off-by: Eric Auger
---
v12 -> v13:
- reword the commit message
v8 -> v9:
- reword the title an
29 matches
Mail list logo
