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
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
> 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
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
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
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
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, 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
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
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
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
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
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
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
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
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
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 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.
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
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
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 ++
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: 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
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
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.
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
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
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 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
38 matches
Mail list logo
