On Wed, Mar 25, 2020 at 04:17:05PM -0700, Jacob Pan wrote:
> Having a single UAPI version to govern the user-kernel data structures
> makes compatibility check straightforward. On the contrary, supporting
> combinations of multiple versions of the data can be a nightmare to
> maintain.
>
> This pa
We don't currently support IOMMUs with a page granule larger than the
system page size. The IOVA allocator has a BUG_ON() in this case, and
VFIO has a WARN_ON().
Removing these obstacles ranges doesn't seem possible without major
changes to the DMA API and VFIO. Some callers of iommu_map(), for
ex
A collection of fixes for the virtio-iommu driver. It might be too late
for v5.6 since they need more review. Patch 2 is new, the others were
posted separately.
Jean-Philippe Brucker (3):
iommu/virtio: Fix sparse warning
iommu/virtio: Fix freeing of incomplete domains
iommu/virtio: Reject I
We copied the virtio_iommu_config from the virtio-iommu specification,
which declares the fields using little-endian annotations (for example
le32). Unfortunately this causes sparse to warn about comparison between
little- and cpu-endian, because of the typecheck() in virtio_cread():
drivers/iommu
Calling viommu_domain_free() on a domain that hasn't been finalised (not
attached to any device, for example) can currently cause an Oops,
because we attempt to call ida_free() on ID 0, which may either be
unallocated or used by another domain.
Only initialise the vdomain->viommu pointer, which de
On 2020-03-26 9:35 am, Jean-Philippe Brucker wrote:
Calling viommu_domain_free() on a domain that hasn't been finalised (not
attached to any device, for example) can currently cause an Oops,
because we attempt to call ida_free() on ID 0, which may either be
unallocated or used by another domain.
On 2020-03-26 9:35 am, Jean-Philippe Brucker wrote:
We don't currently support IOMMUs with a page granule larger than the
system page size. The IOVA allocator has a BUG_ON() in this case, and
VFIO has a WARN_ON().
Removing these obstacles ranges doesn't seem possible without major
changes to the
> From: Liu, Yi L
> Sent: Sunday, March 22, 2020 8:32 PM
> To: alex.william...@redhat.com; eric.au...@redhat.com
> Subject: [PATCH v1 0/8] vfio: expose virtual Shared Virtual Addressing to VMs
>
> From: Liu Yi L
>
> Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on
> Intel
Hi,
here is the updated version of the changes to move iommu_fwspec out of
'struct device'. Previous versions of this patch-set can be found here:
v3: https://lore.kernel.org/lkml/20200320091414.3941-1-j...@8bytes.org/
v2: https://lore.kernel.org/lkml/20200310091229.29830-1-j...@
Hi Robin,
On Wed, Mar 25, 2020 at 12:31:46PM +, Robin Murphy wrote:
> Oops, sorry - as you might imagine I'm not in my normal workflow :)
No problem, nobody is right now :)
> Let me rebase that onto something actually in your tree (rather than
> whatever detached HEAD this is checked out out
From: Joerg Roedel
The term dev_iommu aligns better with other existing structures and
their accessor functions.
Cc: Greg Kroah-Hartman
Tested-by: Will Deacon # arm-smmu
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 28 ++
From: Joerg Roedel
Use the accessor functions instead of directly dereferencing
dev->iommu_fwspec.
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ms
From: Joerg Roedel
Make use of dev_iommu_priv_set/get() functions and simplify the code
where possible with this change.
Tested-by: Will Deacon # arm-smmu
Signed-off-by: Joerg Roedel
---
drivers/iommu/arm-smmu.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --g
From: Joerg Roedel
Some unrelated changes in the iommu code caused a new warning to
appear in the arm-smmu driver:
CC drivers/iommu/arm-smmu.o
drivers/iommu/arm-smmu.c: In function 'arm_smmu_add_device':
drivers/iommu/arm-smmu.c:1441:2: warning: 'smmu' may be used uninitialized in
this f
From: Joerg Roedel
Make use of dev_iommu_priv_set/get() functions.
Signed-off-by: Joerg Roedel
---
drivers/iommu/qcom_iommu.c | 61 ++
1 file changed, 36 insertions(+), 25 deletions(-)
diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
ind
From: Joerg Roedel
Make use of dev_iommu_priv_set/get() functions.
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
drivers/iommu/virtio-iommu.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virti
From: Joerg Roedel
There are users outside of the IOMMU code that need to call that
function. Define it for !CONFIG_IOMMU_API too so that compilation does
not break.
Reported-by: kbuild test robot
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
include/linux/iommu.h | 4 ++
From: Joerg Roedel
Use the accessor functions instead of directly dereferencing
dev->iommu_fwspec.
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
drivers/iommu/tegra-gart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/tegra-gart.c b/dri
From: Joerg Roedel
Move the iommu_fwspec pointer in struct device into struct dev_iommu.
This is a step in the effort to reduce the iommu related pointers in
struct device to one.
Cc: Greg Kroah-Hartman
Tested-by: Will Deacon # arm-smmu
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg
From: Joerg Roedel
Use the accessor functions instead of directly dereferencing
dev->iommu_fwspec.
Tested-by: Hanjun Guo
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
drivers/acpi/arm64/iort.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/driv
From: Joerg Roedel
Make use of dev_iommu_priv_set/get() functions.
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
drivers/iommu/ipmmu-vmsa.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
i
From: Robin Murphy
In preparation for restructuring iommu_fwspec, refactor the way we
access the arm_smmu_master_cfg private data to be less dependent on
the current layout.
Signed-off-by: Robin Murphy
Signed-off-by: Joerg Roedel
---
drivers/iommu/arm-smmu.c | 42 +
From: Joerg Roedel
Make use of dev_iommu_priv_set/get() functions in the code.
Tested-by: Hanjun Guo
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
drivers/iommu/arm-smmu-v3.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/arm
From: Joerg Roedel
Make use of dev_iommu_priv_set/get() functions.
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
drivers/iommu/mtk_iommu.c| 13 ++---
drivers/iommu/mtk_iommu_v1.c | 14 +++---
2 files changed, 13 insertions(+), 14 deletions(-)
diff --g
From: Joerg Roedel
Add dev_iommu_priv_get/set() functions to access per-device iommu
private data. This makes it easier to move the pointer to a different
location.
Tested-by: Will Deacon # arm-smmu
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
include/linux/iommu.h | 10
From: Joerg Roedel
Move the pointer for iommu private data from struct iommu_fwspec to
struct dev_iommu.
Tested-by: Will Deacon # arm-smmu
Reviewed-by: Jean-Philippe Brucker
Signed-off-by: Joerg Roedel
---
include/linux/iommu.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
di
On Thu, Mar 26, 2020 at 04:08:31PM +0100, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Move the iommu_fwspec pointer in struct device into struct dev_iommu.
> This is a step in the effort to reduce the iommu related pointers in
> struct device to one.
>
> Cc: Greg Kroah-Hartman
> Tested-by: Wil
On Thu, Mar 26, 2020 at 04:08:30PM +0100, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The term dev_iommu aligns better with other existing structures and
> their accessor functions.
>
> Cc: Greg Kroah-Hartman
> Tested-by: Will Deacon # arm-smmu
> Reviewed-by: Jean-Philippe Brucker
> Signed-o
Hi Christoph,
Thanks for the review. Please see my comments inline.
On Thu, 26 Mar 2020 02:23:16 -0700
Christoph Hellwig wrote:
> On Wed, Mar 25, 2020 at 04:17:05PM -0700, Jacob Pan wrote:
> > Having a single UAPI version to govern the user-kernel data
> > structures makes compatibility check s
The swiotlb is a very convenient fallback mechanism for bounce buffering of
DMAable data. It is usually used for the compatibility case where devices
can only DMA to a "low region".
However, in some scenarios this "low region" may be bound even more
heavily. For example, there are embedded system
On Thu, Mar 26, 2020 at 05:29:22PM +0100, Alexander Graf wrote:
> The swiotlb is a very convenient fallback mechanism for bounce buffering of
> DMAable data. It is usually used for the compatibility case where devices
> can only DMA to a "low region".
>
> However, in some scenarios this "low regio
On 26.03.20 18:05, Christoph Hellwig wrote:
On Thu, Mar 26, 2020 at 05:29:22PM +0100, Alexander Graf wrote:
The swiotlb is a very convenient fallback mechanism for bounce buffering of
DMAable data. It is usually used for the compatibility case where devices
can only DMA to a "low region".
H
On Thu, 2020-03-26 at 18:11 +0100, Alexander Graf wrote:
> I'm with you on that sentiment, but in the environment I'm currently
> looking at, we have neither DT nor ACPI: The kernel gets purely
> configured via kernel command line. For other unenumerable artifacts on
> the system, such as virtio
Hi Jean,
On 3/26/20 10:35 AM, Jean-Philippe Brucker wrote:
> We don't currently support IOMMUs with a page granule larger than the
> system page size. The IOVA allocator has a BUG_ON() in this case, and
> VFIO has a WARN_ON().
>
> Removing these obstacles ranges doesn't seem possible without majo
Hi Baolu,
On Thu, 26 Mar 2020 10:12:36 +0800
Lu Baolu wrote:
> On 2020/3/26 1:55, Jacob Pan wrote:
> > IOASID set defines a group of IDs that share the same token. The
> > ioasid_set concept helps to do permission checking among users as
> > in the current code.
> >
> > With guest SVA usage, ea
> From: Jacob Pan
> Sent: Friday, March 27, 2020 12:45 AM
>
> Hi Christoph,
>
> Thanks for the review. Please see my comments inline.
>
> On Thu, 26 Mar 2020 02:23:16 -0700
> Christoph Hellwig wrote:
>
> > On Wed, Mar 25, 2020 at 04:17:05PM -0700, Jacob Pan wrote:
> > > Having a single UAPI v
On 2020/3/26 23:08, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Use the accessor functions instead of directly dereferencing
> dev->iommu_fwspec.
>
> Tested-by: Hanjun Guo
> Reviewed-by: Jean-Philippe Brucker
> Signed-off-by: Joerg Roedel
> ---
> drivers/acpi/arm64/iort.c | 6 --
> 1 fi
Hi Jean,
> -Original Message-
> From: Auger Eric
> Sent: Thursday, March 26, 2020 11:11 PM
> To: Jean-Philippe Brucker ; iommu@lists.linux-
> foundation.org
> Cc: virtualizat...@lists.linux-foundation.org; j...@8bytes.org;
> m...@redhat.com;
> jasow...@redhat.com; Bharat Bhushan
> Subje
38 matches
Mail list logo
