Hi
On 2018-09-17 05:24, zhe...@windriver.com wrote:
> From: He Zhe
>
> early_cma does not check input argument before passing it to
> simple_strtoull. The argument would be a NULL pointer if "cma", without
> its value, is set in command line and thus causes the following panic.
>
> PANIC: early
ACPI HID devices do not actually have an alias for
them in the IVRS. But dev_data->alias is still used
for indexing into the IOMMU device table for devices
being handled by the IOMMU. So for ACPI HID devices,
we simply return the corresponding devid as an alias,
as parsed from IVRS table.
On Mon, Sep 17, 2018 at 08:37:45AM -0400, Jerome Glisse wrote:
> Date: Mon, 17 Sep 2018 08:37:45 -0400
> From: Jerome Glisse
> To: Kenneth Lee
> CC: Kenneth Lee , Herbert Xu
> , k...@vger.kernel.org, Jonathan Corbet
> , Greg Kroah-Hartman , Joerg
> Roedel , linux-...@vger.kernel.org, Sanjay
On 2018-09-18 6:10 PM, Will Deacon wrote:
Hi Robin,
On Fri, Sep 14, 2018 at 03:30:20PM +0100, Robin Murphy wrote:
From: Zhen Lei
1. Save the related domain pointer in struct iommu_dma_cookie, make iovad
capable call domain->ops->flush_iotlb_all to flush TLB.
2. During the iommu domain
On 2018-09-18 6:10 PM, Will Deacon wrote:
On Fri, Sep 14, 2018 at 03:30:23PM +0100, Robin Murphy wrote:
From: Zhen Lei
Dynamically choose strict or non-strict mode for page table config based
on the iommu domain type.
It's the domain type in conjunction with the attribute that determines
On 09/18/2018 04:59 AM, Robin Murphy wrote:
Hi Stephen,
On 17/09/18 22:36, Stephen Warren wrote:
Joerg, Christoph, Marek, Robin,
I believe that the driver for our PCIe endpoint controller hardware
will need to explicitly manage its IOVA space more than current APIs
allow. I'd like to
Hi Will,
On 2018-09-18 6:10 PM, Will Deacon wrote:
Hi Robin,
Thanks for turning this around so quickly.
Cheers for a pretty rapid review too :)
On Fri, Sep 14, 2018 at 03:30:18PM +0100, Robin Murphy wrote:
Since we'd like to get this polished up and merged and Leizhen has other
On 2018-09-18 6:10 PM, Will Deacon wrote:
On Fri, Sep 14, 2018 at 03:30:22PM +0100, Robin Murphy wrote:
From: Zhen Lei
Add a bootup option to make the system manager can choose which mode to
be used. The default mode is strict.
Signed-off-by: Zhen Lei
[rm: move handling out of SMMUv3
On 2018-09-18 6:10 PM, Will Deacon wrote:
On Fri, Sep 14, 2018 at 03:30:24PM +0100, Robin Murphy wrote:
All we need is to wire up .flush_iotlb_all properly and implement the
domain attribute, and iommu-dma and io-pgtable-arm will do the rest for
us. Rather than bother implementing it for v7s
On 14/09/2018 22:04, Jacob Pan wrote:
>> This example only needs to modify first-level translation, and works
>> with SMMUv3. The kernel here could be the host, in which case
>> second-level translation is disabled in the SMMU, or it could be the
>> guest, in which case second-level mappings are
On Tue, Sep 18, 2018 at 02:28:42PM +0100, Robin Murphy wrote:
> On 17/09/18 16:38, Christoph Hellwig wrote:
>> Hi all,
>>
>> this series starts with various swiotlb cleanups, then adds support for
>> non-cache coherent devices to the generic swiotlb support, and finally
>> switches arm64 to use
On 15/09/2018 03:36, Tian, Kevin wrote:
>> 4) Userspace opens another mdev.
>> -> iommu.c calls domain->ops->attach_dev(domain2, dev)
>
> another mdev in same VFIO container or different? I assume the
> latter since you mentioned a new domain2.
I was thinking a different VFIO container actually.
On Fri, Sep 14, 2018 at 03:30:24PM +0100, Robin Murphy wrote:
> All we need is to wire up .flush_iotlb_all properly and implement the
> domain attribute, and iommu-dma and io-pgtable-arm will do the rest for
> us. Rather than bother implementing it for v7s format for the highly
> unlikely chance
Hi Robin,
On Fri, Sep 14, 2018 at 03:30:20PM +0100, Robin Murphy wrote:
> From: Zhen Lei
>
> 1. Save the related domain pointer in struct iommu_dma_cookie, make iovad
>capable call domain->ops->flush_iotlb_all to flush TLB.
> 2. During the iommu domain initialization phase, base on
On Fri, Sep 14, 2018 at 03:30:22PM +0100, Robin Murphy wrote:
> From: Zhen Lei
>
> Add a bootup option to make the system manager can choose which mode to
> be used. The default mode is strict.
>
> Signed-off-by: Zhen Lei
> [rm: move handling out of SMMUv3 driver]
> Signed-off-by: Robin Murphy
On Fri, Sep 14, 2018 at 03:30:23PM +0100, Robin Murphy wrote:
> From: Zhen Lei
>
> Dynamically choose strict or non-strict mode for page table config based
> on the iommu domain type.
It's the domain type in conjunction with the attribute that determines
whether we use lazy or strict
Hi Robin,
Thanks for turning this around so quickly.
On Fri, Sep 14, 2018 at 03:30:18PM +0100, Robin Murphy wrote:
> Since we'd like to get this polished up and merged and Leizhen has other
> commitments, here's v7 of the previous series[1] wherein I address all
> my own feedback :) This is a
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Tuesday, September 18, 2018 11:52 PM
>
> On 15/09/2018 03:36, Tian, Kevin wrote:
> >> 4) Userspace opens another mdev.
> >> -> iommu.c calls domain->ops->attach_dev(domain2, dev)
> >
> > another mdev in same VFIO
Hi,
On 09/19/2018 07:26 AM, Tian, Kevin wrote:
From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
Sent: Tuesday, September 18, 2018 11:52 PM
On 15/09/2018 03:36, Tian, Kevin wrote:
4) Userspace opens another mdev.
-> iommu.c calls domain->ops->attach_dev(domain2, dev)
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Tuesday, September 18, 2018 11:47 PM
>
> On 14/09/2018 22:04, Jacob Pan wrote:
> >> This example only needs to modify first-level translation, and works
> >> with SMMUv3. The kernel here could be the host, in which case
Hi Joerg,
can you please pull this patch?
On Wed, Sep 5, 2018 at 9:58 AM Ganapatrao Kulkarni
wrote:
>
> As an optimisation for PCI devices, there is always first attempt
> been made to allocate iova from SAC address range. This will lead
> to unnecessary attempts, when there are no free ranges
On Wed, 12 Sep 2018 10:46:19 -0700
"Raj, Ashok" wrote:
> On Thu, Aug 09, 2018 at 01:44:17PM -0600, Alex Williamson wrote:
> > On Thu, 9 Aug 2018 12:37:06 -0700
> > Ashok Raj wrote:
> >
> > > PCI_INTERRUPT_PIN should always read 0 for SRIOV Virtual
> > > Functions.
> > >
> > > Some SRIOV
Hi Stephen,
On 17/09/18 22:36, Stephen Warren wrote:
Joerg, Christoph, Marek, Robin,
I believe that the driver for our PCIe endpoint controller hardware will
need to explicitly manage its IOVA space more than current APIs allow.
I'd like to discuss how to make that possible.
First some
This series allows a virtualizer to program the nested stage mode.
This is useful when both the host and the guest are exposed with
an SMMUv3 and a PCI device is assigned to the guest using VFIO.
In this mode, the physical IOMMU must be programmed to translate
the two stages: the one set up by
From: Jacob Pan
In virtualization use case, when a guest is assigned
a PCI host device, protected by a virtual IOMMU on a 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
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
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
From: "Liu, Yi L"
This patch adds VFIO_IOMMU_BIND_PASID_TABLE ioctl which aims at
passing the virtual iommu guest configuration to the VFIO driver
downto to the iommu subsystem.
Signed-off-by: Jacob Pan
Signed-off-by: Liu, Yi L
Signed-off-by: Eric Auger
---
v1 -> v2:
-
From: "Liu, Yi L"
In any virtualization use case, when the first translation stage
is "owned" by the guest OS, the host IOMMU driver has no knowledge
of caching structure updates unless the guest invalidation activities
are trapped by the virtualizer and passed down to the host.
Since the
The bind_guest_msi() callback checks the domain
is NESTED and redirect to the dma-iommu implementation.
Signed-off-by: Eric Auger
---
drivers/iommu/arm-smmu-v3.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
Implement IOMMU_INV_TYPE_TLB invalidations. When
nr_pages is null we interpret this as a context
invalidation.
Signed-off-by: Eric Auger
---
The user API needs to be refined to discriminate context
invalidations from NH_VA invalidations. Also the leaf attribute
is not yet properly handled.
v1
From: Jean-Philippe Brucker
When removing a mapping from a domain, we need to send an invalidation to
all devices that might have stored it in their Address Translation Cache
(ATC). In addition with SVM, we'll need to invalidate context descriptors
of all devices attached to a live domain.
On bind_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 guest wanted to bypass the stage 1 or induce
aborts for this STE.
On unbind, the STE stage 1 fields are reset.
Up to now, when the type was UNMANAGED, we used to
allocate IOVA pages within a range provided by the user.
This does not work in nested mode.
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
From: Jean-Philippe Brucker
When handling faults from the event or PRI queue, we need to find the
struct device associated to a SID. Add a rb_tree to keep track of SIDs.
Signed-off-by: Jean-Philippe Brucker
---
drivers/iommu/arm-smmu-v3.c | 136 ++--
1 file
To allow nested stage support, we need to store both
stage 1 and stage 2 configurations (and remove the former
union).
arm_smmu_write_strtab_ent() is modified to write both stage
fields in the STE.
We add a nested_bypass field to the S1 configuration as the first
stage can be bypassed. Also the
This patch adds the VFIO_IOMMU_BIND_MSI ioctl which aims at
passing the guest MSI binding to the host.
Signed-off-by: Eric Auger
---
v1 -> v2:
- s/vfio_iommu_type1_guest_msi_binding/vfio_iommu_type1_bind_guest_msi
---
drivers/vfio/vfio_iommu_type1.c | 31 +++
VFIO_IOMMU_SET_FAULT_EVENTFD Allows to associate a fault
event handler to a container. This is useful when the
guest owns the first translation stage and the host uses
the second stage. As the guest translation is fully handled
by the physical IOMMU, if any fault happens, this latter needs
to be
Introduce an IOTCL that allows the userspace to consume fault
events that may have occurred. The userspace buffer gets filled
by pending faults, if any. The number of filled faults is
reported to the userspace. Read faults are removed from the kfifo.
the kernel does not expect any response from
From: Jacob Pan
Device faults detected by IOMMU can be reported outside IOMMU
subsystem for further processing. This patch intends to provide
a generic device fault data such that device drivers can be
communicated with IOMMU faults without model specific knowledge.
The proposed format is the
From: Jacob Pan
Traditionally, device specific faults are detected and handled within
their own device drivers. When IOMMU is enabled, faults such as DMA
related transactions are detected by IOMMU. There is no generic
reporting mechanism to report faults back to the in-kernel device
driver or
From: Jacob Pan
DMA faults can be detected by IOMMU at device level. Adding a pointer
to struct device allows IOMMU subsystem to report relevant faults
back to the device driver for further handling.
For direct assigned device (or user space drivers), guest OS holds
responsibility to handle and
New iotcls were introduced to pass information about guest stage1
to the host through VFIO. Let's document the nested stage control.
Signed-off-by: Eric Auger
---
fault reporting is current missing to the picture
v1 -> v2:
- use the new ioctl names
- add doc related to fault handling
---
When a stage 1 related fault event is read from the event queue,
let's propagate it to potential external fault listeners, ie. users
who registered a fault handler.
Signed-off-by: Eric Auger
---
drivers/iommu/arm-smmu-v3.c | 124
1 file changed, 113
On 2018-09-18 03:06, Stephen Warren wrote:
Joerg, Christoph, Marek, Robin,
I believe that the driver for our PCIe endpoint controller hardware
will need to explicitly manage its IOVA space more than current APIs
allow. I'd like to discuss how to make that possible.
First some background on
Hi Christoph,
On 17/09/18 16:38, Christoph Hellwig wrote:
Hi all,
this series starts with various swiotlb cleanups, then adds support for
non-cache coherent devices to the generic swiotlb support, and finally
switches arm64 to use the generic code.
I think there's going to be an issue with
>Not sure how fast Tom needs the common dma-iommu code for the x86 AMD iommu
>conversion.
I am currently busy working on something else and won't be able to
do/test the x86 AMD iommu conversion anytime soon. So I don't need the
common dma-iommu code anytime soon.
On 17 September 2018 at 14:33,
On Tue, Sep 18, 2018 at 02:00:14PM +0800, Kenneth Lee wrote:
> On Mon, Sep 17, 2018 at 08:37:45AM -0400, Jerome Glisse wrote:
> > On Mon, Sep 17, 2018 at 04:39:40PM +0800, Kenneth Lee wrote:
> > > On Sun, Sep 16, 2018 at 09:42:44PM -0400, Jerome Glisse wrote:
> > > > So i want to summarize issues
This patch fixes a typo in iommu.c.
Signed-off-by: Rami Rosen
---
drivers/iommu/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index f3698006cb53..022020144f33 100644
--- a/drivers/iommu/iommu.c
+++
49 matches
Mail list logo
