The following changes since commit 9f5f8ec50165630cfc49897410b30997d4d677b5:
dma-mapping: benchmark: use u8 for reserved field in uAPI structure
(2021-02-05 12:48:46 +0100)
are available in the Git repository at:
git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.12
for y
Hi Eric,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v5.11]
[also build test ERROR on next-20210223]
[cannot apply to vfio/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--bas
Hi Eric,
I love your patch! Yet something to improve:
[auto build test ERROR on v5.11]
[cannot apply to vfio/next next-20210223]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-sc
Hi Eric,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v5.11]
[also build test ERROR on next-20210223]
[cannot apply to vfio/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--bas
Hi Eric,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v5.11]
[also build test ERROR on next-20210223]
[cannot apply to vfio/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--bas
From: Tina Zhang
Caps the number of irqs with fixed indexes and uses capability chains
to chain device specific irqs.
Signed-off-by: Tina Zhang
Signed-off-by: Eric Auger
[Eric: Put cap_offset at the end of the vfio_irq_info struct,
remove GFX IRQ at the moment and remove any reference to this
Register the VFIO_IRQ_TYPE_NESTED/VFIO_IRQ_SUBTYPE_DMA_FAULT
IRQ that allows to signal a nested mode DMA fault.
Signed-off-by: Eric Auger
---
v10 -> v11:
- the irq now is registered in vfio_pci_dma_fault_init()
in case the domain is nested
---
drivers/vfio/pci/vfio_pci.c | 21 +++
When the userspace increments the head of the page response
buffer ring, let's push the response into the iommu layer.
This is done through a workqueue that pops the responses from
the ring buffer and increment the tail.
Signed-off-by: Eric Auger
---
drivers/vfio/pci/vfio_pci.c | 40
In preparation for vSVA, let's register a DMA fault response region,
where the userspace will push the page responses and increment the
head of the buffer. The kernel will pop those responses and inject them
on iommu side.
Signed-off-by: Eric Auger
---
v11 -> v12:
- use DMA_FAULT_RESPONSE cap [
Implement IRQ capability chain infrastructure. All interrupt
indexes beyond VFIO_PCI_NUM_IRQS are handled as extended
interrupts. They are registered with a specific type/subtype
and supported flags.
Signed-off-by: Eric Auger
---
v11 -> v12:
- check !vdev->num_ext_irqs in vfio_pci_set_ext_irq_t
The VFIO API was enhanced to support nested stage control: a bunch of
new iotcls, one DMA FAULT region and an associated specific IRQ.
Let's document the process to follow to set up nested mode.
Signed-off-by: Eric Auger
---
v11 -> v12:
s/VFIO_REGION_INFO_CAP_PRODUCER_FAULT/VFIO_REGION_INFO_CA
The DMA FAULT region contains the fault ring buffer.
There is benefit to let the userspace mmap this area.
Expose this mmappable area through a sparse mmap entry
and implement the mmap operation.
Signed-off-by: Eric Auger
---
v8 -> v9:
- remove unused index local variable in vfio_pci_fault_mmap
Register an IOMMU fault handler which records faults in
the DMA FAULT region ring buffer. In a subsequent patch, we
will add the signaling of a specific eventfd to allow the
userspace to be notified whenever a new fault has shown up.
Signed-off-by: Eric Auger
---
v11 -> v12:
- take the fault_que
Add a new IRQ type/subtype to get notification on nested
stage DMA faults.
Signed-off-by: Eric Auger
---
include/uapi/linux/vfio.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 3688215843fe..f0eea0f9305a 100644
--- a/include/ua
This series brings the VFIO part of HW nested paging support
in the SMMUv3.
This is a rebase on top of v5.11
The series depends on:
[PATCH v14 00/13] SMMUv3 Nested Stage Setup (IOMMU part)
3 new IOCTLs are introduced that allow the userspace to
1) pass the guest stage 1 configuration
2) pass sta
From: "Liu, Yi L"
This patch adds an VFIO_IOMMU_SET_PASID_TABLE ioctl
which aims to pass the virtual iommu guest configuration
to the host. This latter takes the form of the so-called
PASID table.
Signed-off-by: Jacob Pan
Signed-off-by: Liu, Yi L
Signed-off-by: Eric Auger
---
v11 -> v12:
- u
This patch adds the VFIO_IOMMU_SET_MSI_BINDING ioctl which aim
to (un)register the guest MSI binding to the host. This latter
then can use those stage 1 bindings to build a nested stage
binding targeting the physical MSIs.
Signed-off-by: Eric Auger
---
v11 -> v12:
- Share VFIO_BASE + 20 with VF
Add a new specific DMA_FAULT region aiming to exposed nested mode
translation faults. This region only is exposed if the device
is attached to a nested domain.
The region has a ring buffer that contains the actual fault
records plus a header allowing to handle it (tail/head indices,
max capacity,
From: "Liu, Yi L"
When the guest "owns" the stage 1 translation structures, the host
IOMMU driver has no knowledge of caching structure updates unless
the guest invalidation requests are trapped and passed down to the
host.
This patch adds the VFIO_IOMMU_CACHE_INVALIDATE ioctl with aims
at prop
In preparation for vSVA, let's accept userspace provided configs
with more than one CD. We check the max CD against the host iommu
capability and also the format (linear versus 2 level).
Signed-off-by: Eric Auger
Signed-off-by: Shameer Kolothum
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |
Up to now, when the type was UNMANAGED, we used to
allocate IOVA pages within a reserved IOVA MSI range.
If both the host and the guest are exposed with SMMUs, each
would allocate an IOVA. The guest allocates an IOVA (gIOVA)
to map onto the guest MSI doorbell (gDB). The Host allocates
another IOVA
Up to now we have only reported translation faults. Now that
the guest can induce some configuration faults, let's report them
too. Add propagation for BAD_SUBSTREAMID, CD_FETCH, BAD_CD, WALK_EABT.
We also fix the transcoding for some existing translation faults.
Signed-off-by: Eric Auger
---
dr
The bind/unbind_guest_msi() callbacks check the domain
is NESTED and redirect to the dma-iommu implementation.
Signed-off-by: Eric Auger
---
v6 -> v7:
- remove device handle argument
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 43 +
1 file changed, 43 insertions(+)
d
In nested mode we enforce the rule that all devices belonging
to the same iommu_domain share the same msi_domain.
Indeed if there were several physical MSI doorbells being used
within a single iommu_domain, it becomes really difficult to
resolve the nested stage mapping translating into the correc
Nested mode currently is not compatible with HW MSI reserved regions.
Indeed MSI transactions targeting this MSI doorbells bypass the SMMU.
Let's check nested mode is not attempted in such configuration.
Signed-off-by: Eric Auger
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 23
Implement domain-selective, pasid selective and page-selective
IOTLB invalidations.
Signed-off-by: Eric Auger
---
v13 -> v14:
- Add domain invalidation
- do global inval when asid is not provided with addr
granularity
v7 -> v8:
- ASID based invalidation using iommu_inv_pasid_info
- check ARC
On attach_pasid_table() we program STE S1 related info set
by the guest into the actual physical STEs. At minimum
we need to program the context descriptor GPA and compute
whether the stage1 is translated/bypassed or aborted.
On detach, the stage 1 config is unset and the abort flag is
unset.
Sig
With nested stage support, soon we will need to invalidate
S1 contexts and ranges tagged with an unmanaged asid, this
latter being managed by the guest. So let's introduce 2 helpers
that allow to invalidate with externally managed ASIDs
Signed-off-by: Eric Auger
---
v13 -> v14
- Actually send t
This series brings the IOMMU part of HW nested paging support
in the SMMUv3. The VFIO part is submitted separately.
This is based on Jean-Philippe's
[PATCH v12 00/10] iommu: I/O page faults for SMMUv3
https://lore.kernel.org/linux-arm-kernel/YBfij71tyYvh8LhB@myrica/T/
The IOMMU API is extended to
When nested stage translation is setup, both s1_cfg and
s2_cfg are set.
We introduce a new smmu_domain abort field that will be set
upon guest stage1 configuration passing. If no guest stage1
config has been attached, it is ignored when writing the STE.
arm_smmu_write_strtab_ent() is modified to
In true nested mode, both s1_cfg and s2_cfg will coexist.
Let's remove the union and add a "set" field in each
config structure telling whether the config is set and needs
to be applied when writing the STE. In legacy nested mode,
only the second stage is used. In true nested mode, both stages
are
On ARM, MSI are translated by the SMMU. An IOVA is allocated
for each MSI doorbell. If both the host and the guest are exposed
with SMMUs, we end up with 2 different IOVAs allocated by each.
guest allocates an IOVA (gIOVA) to map onto the guest MSI
doorbell (gDB). The Host allocates another IOVA (h
In virtualization use case, when a guest is assigned
a PCI host device, protected by a virtual IOMMU on the guest,
the physical IOMMU must be programmed to be consistent with
the guest mappings. If the physical IOMMU supports two
translation stages it makes sense to program guest mappings
onto the
Hi Shenming,
On 2/23/21 1:45 PM, Shenming Lu wrote:
>> +static int vfio_pci_dma_fault_init(struct vfio_pci_device *vdev)
>> +{
>> +struct vfio_region_dma_fault *header;
>> +struct iommu_domain *domain;
>> +size_t size;
>> +bool nested;
>> +int ret;
>> +
>> +domain = iommu_g
> +static int vfio_pci_dma_fault_init(struct vfio_pci_device *vdev)
> +{
> + struct vfio_region_dma_fault *header;
> + struct iommu_domain *domain;
> + size_t size;
> + bool nested;
> + int ret;
> +
> + domain = iommu_get_domain_for_dev(&vdev->pdev->dev);
> + ret = iommu
Hi Christoph,
Please see the bisection report below about a boot failure on
r8a77960-ulcb on next-20210222.
Reports aren't automatically sent to the public while we're
trialing new bisection features on kernelci.org but this one
looks valid.
The log shows a kernel panic, more details can be fo
36 matches
Mail list logo
