On Fri, Mar 25, 2022 at 11:46:09AM -0700, Linus Torvalds wrote:
> I think my list of three different sync cases (not just two! It's not
> just about whether to sync for the CPU or the device, it's also about
> what direction the data itself is taking) is correct.
>
> But maybe I'm wrong.
At the
From: Christoph Hellwig
> Sent: 28 March 2022 07:37
>
> On Fri, Mar 25, 2022 at 11:46:09AM -0700, Linus Torvalds wrote:
> > I think my list of three different sync cases (not just two! It's not
> > just about whether to sync for the CPU or the device, it's also about
> > what direction the data
Hi David,
On 2022/3/22 14:35, David Stevens wrote:
From: David Stevens
Calculate the appropriate mask for non-size-aligned page selective
invalidation. Since psi uses the mask value to mask out the lower order
bits of the target address, properly flushing the iotlb requires using a
mask value
Hi Daniel,
On 2022/3/26 6:10, Alex Williamson wrote:
Hi Daniel,
On Fri, 25 Mar 2022 13:06:40 -0700
"Daniel F. Smith" wrote:
This email is to document an insidious (incorrect data, no error or warning)
VFIO bug found when using the Intel IOMMU to perform DMA transfers; and the
associated
Joerg,
Ping.
-Vasant
On 3/14/2022 12:32 PM, Vasant Hegde via iommu wrote:
> smatch static checker warning:
> drivers/iommu/amd/init.c:1989 amd_iommu_init_pci()
> warn: duplicate check 'ret' (previous on line 1978)
>
> Reported-by: Dan Carpenter
> Fixes: 06687a03805e ("iommu/amd: Improve
On Sun, 2022-03-27 at 05:15 +0200, Halil Pasic wrote:
>
> The key here is "sync_sg API, all the parameters must be the same
> as those passed into the single mapping API", but I have to admit,
> I don't understand the *single* in here.
>
Hah. So I wasn't imagining things after all.
However,
On Mon, 2022-03-28 at 11:50 +0200, Johannes Berg wrote:
> No I worded that badly - the direction isn't useless, but thinking of it
> in terms of a buffer property rather than data movement is inaccurate.
> So then if we need something else to indicate how data was expected to
> be moved, the
On Mon, 2022-03-28 at 09:53 +0800, Jason Wang wrote:
> On Thu, Mar 24, 2022 at 7:46 PM Jason Gunthorpe wrote:
> >
> > On Thu, Mar 24, 2022 at 11:50:47AM +0800, Jason Wang wrote:
> >
> > > It's simply because we don't want to break existing userspace. [1]
> >
> > I'm still waiting to hear what
On Mon, Mar 28, 2022 at 02:14:26PM +0100, Sean Mooney wrote:
> On Mon, 2022-03-28 at 09:53 +0800, Jason Wang wrote:
> > On Thu, Mar 24, 2022 at 7:46 PM Jason Gunthorpe wrote:
> > >
> > > On Thu, Mar 24, 2022 at 11:50:47AM +0800, Jason Wang wrote:
> > >
> > > > It's simply because we don't want
On Sun, 27 Mar 2022 17:30:01 -0700
Linus Torvalds wrote:
> On Sun, Mar 27, 2022 at 4:52 PM Halil Pasic wrote:
> >
> > I have no intention of pursuing this. When fixing the information leak,
> > I happened to realize, that a somewhat similar situation can emerge when
> > mappings are reused. It
On Mon, 2022-03-28 at 11:48 +0200, Johannes Berg wrote:
>
> However, this basically means that the direction argument to the flush
> APIs are completely useless, and we do have to define something
> new/else...
>
No I worded that badly - the direction isn't useless, but thinking of it
in terms
On Mon, Mar 28, 2022 at 09:53:27AM +0800, Jason Wang wrote:
> To me, it looks more easier to not answer this question by letting
> userspace know about the change,
That is not backwards compatbile, so I don't think it helps unless we
say if you open /dev/vfio/vfio you get old behavior and if you
On Mon, Mar 28, 2022 at 11:17:23AM -0600, Alex Williamson wrote:
> On Thu, 24 Mar 2022 10:46:22 -0300
> Jason Gunthorpe wrote:
>
> > On Thu, Mar 24, 2022 at 07:25:03AM +, Tian, Kevin wrote:
> >
> > > Based on that here is a quick tweak of the force-snoop part (not
> > > compiled).
> >
>
Hi Alex,
Answers to questions I can answer are in-line. First an apology
though---the machine with the FPGA board is 1000 miles remote, and I don't
have root access. It's unlikely I will be able to do kernel patch testing.
Alex Williamson scribed the following, on or around Fri, Mar 25, 2022
On Thu, 24 Mar 2022 10:46:22 -0300
Jason Gunthorpe wrote:
> On Thu, Mar 24, 2022 at 07:25:03AM +, Tian, Kevin wrote:
>
> > Based on that here is a quick tweak of the force-snoop part (not compiled).
> >
>
> I liked your previous idea better, that IOMMU_CAP_CACHE_COHERENCY
> started out
Add preliminary documentation for AMD IOMMU.
Signed-off-by: Alex Deucher
---
V2: Incorporate feedback from Robin to clarify IOMMU vs DMA engine (e.g.,
a device) and document proper DMA API. Also correct the fact that
the AMD IOMMU is not limited to managing PCI devices.
v3: Fix
Based on feedback from Robin on the initial AMD IOMMU
documentation, fix up the Intel documentation to
clarify IOMMU vs device and modern DMA API.
Signed-off-by: Alex Deucher
---
V2: Fix spelling error in commit message
Rework ACPI section as suggested by Dave Hansen
This was originally just a patch to add an AMD IOMMU
documentation page, but grew into some cleanup of the
Intel IOMMU documentation page.
v2: AMD documentation rework
Add Intel Updates
v3: Further documentation reworks
Alex Deucher (2):
Documentation: x86: Add documentation for AMD IOMMU
On Mon, Mar 28, 2022 at 03:57:53PM -0300, Jason Gunthorpe wrote:
> So, currently AMD and Intel have exactly the same HW feature with a
> different kAPI..
I fixed it like below and made the ordering changes Kevin pointed
to. Will send next week after the merge window:
527e438a974a06 iommu:
Hi Kevin,
On Fri, 18 Mar 2022 05:33:38 +, "Tian, Kevin"
wrote:
> > From: Jacob Pan
> > Sent: Thursday, March 17, 2022 5:02 AM
> >
> > Hi Kevin,
> >
> > On Wed, 16 Mar 2022 07:41:34 +, "Tian, Kevin"
> > wrote:
> >
> > > > From: Jason Gunthorpe
> > > > Sent: Tuesday, March 15, 2022
On Mon, 28 Mar 2022 16:47:49 -0300
Jason Gunthorpe wrote:
> On Mon, Mar 28, 2022 at 03:57:53PM -0300, Jason Gunthorpe wrote:
>
> > So, currently AMD and Intel have exactly the same HW feature with a
> > different kAPI..
>
> I fixed it like below and made the ordering changes Kevin pointed
>
Hi BaoLu,
On Fri, 18 Mar 2022 20:43:54 +0800, Lu Baolu
wrote:
> On 2022/3/15 13:07, Jacob Pan wrote:
> > DMA mapping API is the de facto standard for in-kernel DMA. It operates
> > on a per device/RID basis which is not PASID-aware.
> >
> > Some modern devices such as Intel Data Streaming
Tegra234 has 2 pairs of ARM MMU-500 instances. Each pair is used
together and should be programmed identically.
Add compatible string of Tegra234 iommu nodes in arm_smmu_impl_init()
so that arm-smmu-nvidia implementation will be used for programming
these SMMU instances.
Signed-off-by: Ashish
On Mon, Mar 28, 2022 at 8:23 PM Jason Gunthorpe wrote:
>
> On Mon, Mar 28, 2022 at 09:53:27AM +0800, Jason Wang wrote:
> > To me, it looks more easier to not answer this question by letting
> > userspace know about the change,
>
> That is not backwards compatbile, so I don't think it helps unless
The existing iommu SVA interfaces are implemented by calling the SVA
specific iommu ops provided by the IOMMU drivers. There's no need for
any SVA specific ops in iommu_ops vector anymore as we can achieve
this through the generic attach/detach_dev_pasid domain ops.
This refactors the IOMMU SVA
These ops'es have been replaced with the dev_attach/detach_pasid domain
ops'es. There's no need for them anymore. Remove them to avoid dead
code.
Signed-off-by: Lu Baolu
---
include/linux/intel-iommu.h | 4 --
include/linux/iommu.h | 8 ---
Add a new iommu domain type IOMMU_DOMAIN_SVA to represent an I/O page
table which is shared from CPU host VA. Add some helpers to get and
put an SVA domain and implement SVA domain life cycle management.
Signed-off-by: Lu Baolu
---
include/linux/iommu.h | 7 +++
Some of the interfaces in the IOMMU core require that only a single
kernel device driver controls the device in the IOMMU group. The
existing method is to check the device count in the IOMMU group in
the interfaces. This is unreliable because any device added to the
IOMMU group later breaks this
Attaching an IOMMU domain to a PASID of a device is a generic operation
for modern IOMMU drivers which support PASID-granular DMA address
translation. Currently visible usage scenarios include (but not limited):
- SVA (Shared Virtual Address)
- kernel DMA with PASID
- hardware-assist mediated
The current in-kernel supervisor PASID support is based on the SVA
machinery in SVA lib. The binding between a kernel PASID and kernel
mapping has many flaws. Remove SVM_FLAG_SUPERVISOR_MODE support.
Link: https://lore.kernel.org/linux-iommu/20210511194726.gp1002...@nvidia.com/
Signed-off-by:
Add support for SVA domain allocation and provide an SVA-specific
iommu_domain_ops.
Signed-off-by: Lu Baolu
---
include/linux/intel-iommu.h | 1 +
drivers/iommu/intel/iommu.c | 10 ++
drivers/iommu/intel/svm.c | 37 +
3 files changed, 48
Hi,
The former part of this series refactors the IOMMU SVA code by assigning
an SVA type of iommu_domain to a shared virtual address and replacing
sva_bind/unbind iommu ops with attach/detach_dev_pasid domain ops.
The latter part changes the existing I/O page fault handling framework
from only
Use this field to save the pasid/ssid bits that a device is able to
support with its IOMMU hardware. It is a generic attribute of a device
and lifting it into the per-device dev_iommu struct makes it possible
to allocate a PASID for device without calls into the IOMMU drivers.
Any iommu driver
Add support for SVA domain allocation and provide an SVA-specific
iommu_domain_ops.
Signed-off-by: Lu Baolu
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 14 +++
.../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 42 +++
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 21
Tweak the I/O page fault handling framework to route the page faults to
the domain and call the page fault handler retrieved from the domain.
This makes the I/O page fault handling framework possible to serve more
usage scenarios as long as they have an IOMMU domain and install a page
fault
Rename iommu-sva-lib.c[h] to iommu-sva.c[h] as it contains all code
for SVA implementation in iommu core.
Signed-off-by: Lu Baolu
---
drivers/iommu/{iommu-sva-lib.h => iommu-sva.h} | 0
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 2 +-
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 2
From: Lv Ruyi
kmem_cache_zalloc is a memory allocation function which can return NULL
when some internal memory errors happen. Add null pointer check to avoid
dereferencing null pointer.
Reported-by: Zeal Robot
Signed-off-by: Lv Ruyi
---
drivers/iommu/fsl_pamu_domain.c | 4
1 file
On Mon, 28 Mar 2022 12:14:51 -0700
"Daniel F. Smith" wrote:
> Hi Alex,
>
> Answers to questions I can answer are in-line. First an apology
> though---the machine with the FPGA board is 1000 miles remote, and I don't
> have root access. It's unlikely I will be able to do kernel patch testing.
38 matches
Mail list logo
