> From: Jacob Pan
> Sent: Friday, June 12, 2020 8:27 AM
>
> On Thu, 11 Jun 2020 14:40:47 -0600
> Alex Williamson wrote:
>
> > On Thu, 11 Jun 2020 12:52:05 -0700
> > Jacob Pan wrote:
> >
> > > Hi Alex,
> > >
> > > On Thu, 11 Jun 2020 09:47:41 -0600
> > > Alex Williamson wrote:
> > >
> > > > On
Hi Alex,
> From: Alex Williamson
> Sent: Friday, June 12, 2020 3:30 AM
>
> On Thu, 11 Jun 2020 05:15:21 -0700
> Liu Yi L wrote:
>
> > IOMMUs that support nesting translation needs report the capability
> > info to userspace, e.g. the format of first level/stage paging structures.
> >
> > Cc: K
On Fri, 12 Jun 2020 07:38:44 +
"Tian, Kevin" wrote:
> > From: Jacob Pan
> > Sent: Friday, June 12, 2020 8:27 AM
> >
> > On Thu, 11 Jun 2020 14:40:47 -0600
> > Alex Williamson wrote:
> >
> > > On Thu, 11 Jun 2020 12:52:05 -0700
> > > Jacob Pan wrote:
> > >
> > > > Hi Alex,
> > > >
> >
On Mon, Feb 17, 2020 at 12:08:48PM +, John Garry wrote:
> > >
> > > Right, and even worse is that it relies on the port driver even
> > > existing at all.
> > >
> > > All this iommu group assignment should be taken outside device
> > > driver probe paths.
> > >
> > > However we could still c
Hi Linus,
I am not sure it is the right time to send this. The patches below have
not been part of the IOMMU updates for v5.8, in the AMD case because it
made the merge conflicts even worse, and in the Intel case because it
was not done yet.
It would be good to have both drivers moved in v5.8-rc1
On Thu, Jun 11, 2020 at 08:22:29PM -0700, Rob Clark wrote:
> On Thu, Jun 11, 2020 at 3:29 PM Jordan Crouse wrote:
> >
> > Add support for using per-instance pagetables if all the dependencies are
> > available.
> >
> > Signed-off-by: Jordan Crouse
> > ---
> >
> > drivers/gpu/drm/msm/adreno/a6xx_
On Fri, Jun 12, 2020 at 8:22 AM Joerg Roedel wrote:
>
> I am not sure it is the right time to send this.
Looks good to me. Any time a directory starts to have a lot of
filenames with a particular prefix, moving them deeper like this seems
to make sense. And doing it just before the -rc1 release a
The pull request you sent on Fri, 12 Jun 2020 17:22:10 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/iommu-drivers-move-v5.8
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8f02f363f76f99f08117336cfac7f24c76b25be3
Thank you!
--
Deet-do
On Thu, 11 Jun 2020 14:33:08 +0800
Lu Baolu wrote:
> Hi Jacob,
>
> On 2020/6/11 12:12, Jacob Pan wrote:
> > IOMMU UAPI is newly introduced to support communications between
> > guest virtual IOMMU and host IOMMU. There has been lots of
> > discussions on how it should work with VFIO UAPI and use
Hi Jon,
On Thu, 11 Jun 2020 10:30:32 +0100
Jonathan Cameron wrote:
> On Wed, 10 Jun 2020 21:12:13 -0700
> Jacob Pan wrote:
>
> > IOMMU UAPI is newly introduced to support communications between
> > guest virtual IOMMU and host IOMMU. There has been lots of
> > discussions on how it should work
This patchset imeplements the suggestion from Linus to move the Kconfig
and Makefile bits for AMD and Intel into their respective directories.
It also cleans up a couple Kconfig entries to use the newer help
attribute instead of ---help--- (complaint from checkpatch).
Jerry Snitselaar (2):
i
Move Intel Kconfig and Makefile bits down into intel directory
with the rest of the Intel specific files.
Cc: Joerg Roedel
Cc: Lu Baolu
Signed-off-by: Jerry Snitselaar
---
drivers/iommu/Kconfig| 86 +---
drivers/iommu/Makefile | 8 +---
drivers/io
Move AMD Kconfig and Makefile bits down into the amd directory
with the rest of the AMD specific files.
Cc: Joerg Roedel
Cc: Suravee Suthikulpanit
Signed-off-by: Jerry Snitselaar
---
drivers/iommu/Kconfig | 45 +-
drivers/iommu/Makefile | 5 +
"flags" passed to intel_svm_bind_mm() is a bit mask and should be
defined as "unsigned int" instead of "int".
Change its type to "unsigned int".
Suggested-by: Thomas Gleixner
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Add this new patch per Thomas' comment.
drivers/iommu/inte
Typical hardware devices require a driver stack to translate application
buffers to hardware addresses, and a kernel-user transition to notify the
hardware of new work. What if both the translation and transition overhead
could be eliminated? This is what Shared Virtual Address (SVA) and ENQCMD
ena
PASID is shared by all threads in a process. So the logical place to keep
track of it is in the "mm". Both ARM and X86 need to use the PASID in the
"mm".
Suggested-by: Christoph Hellwig
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- This new patch moves "pasid" from x86 specific mm_
The IA32_PASID MSR (0xd93) contains the Process Address Space Identifier
(PASID), a 20-bit value. Bit 31 must be set to indicate the value
programmed in the MSR is valid. Hardware uses PASID to identify process
address space and direct responses to the right address space.
Signed-off-by: Fenghua Y
The PASID state has to be cleared on forks, since the child has a
different address space. The PASID is also cleared for thread clone. While
it would be correct to inherit the PASID in this case, it is unknown
whether the new task will use ENQCMD. Giving it the PASID "just in case"
would have the d
From: Yu-cheng Yu
ENQCMD instruction reads PASID from IA32_PASID MSR. The MSR is stored
in the task's supervisor FPU PASID state and is context switched by
XSAVES/XRSTORS.
Signed-off-by: Yu-cheng Yu
Co-developed-by: Fenghua Yu
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Modify
A PASID is allocated for an "mm" the first time any thread attaches
to an SVM capable device. Later device attachments (whether to the same
device or another SVM device) will re-use the same PASID.
The PASID is freed when the process exits (so no need to keep
reference counts on how many SVM devic
Work submission instruction comes in two flavors. ENQCMD can be called
both in ring 3 and ring 0 and always uses the contents of PASID MSR when
shipping the command to the device. ENQCMDS allows a kernel driver to
submit commands on behalf of a user process. The driver supplies the
PASID value in E
From: Ashok Raj
ENQCMD and Data Streaming Accelerator (DSA) and all of their associated
features are a complicated stack with lots of interconnected pieces.
This documentation provides a big picture overview for all of the
features.
Signed-off-by: Ashok Raj
Co-developed-by: Fenghua Yu
Signed-o
A #GP fault is generated when ENQCMD instruction is executed without
a valid PASID value programmed in the current thread's PASID MSR. The
#GP fault handler will initialize the MSR if a PASID has been allocated
for this process.
Decoding the user instruction is ugly and sets a bad architecture
pre
PASID is defined as a few different types in iommu including "int",
"u32", and "unsigned int". To be consistent and to match with ioasid's
type, define PASID and its variations (e.g. max PASID) as "unsigned int".
No PASID type change in uapi.
Suggested-by: Thomas Gleixner
Signed-off-by: Fenghua
When a new mm is created, its PASID should be cleared, i.e. the PASID is
initialized to its init state 0 on both ARM and X86.
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Add this patch to initialize PASID value for a new mm.
include/linux/mm_types.h | 2 ++
kernel/fork.c
PASID is defined as "int" although it's a 20-bit value and shouldn't be
negative int. To be consistent with type defined in iommu, define PASID
as "unsigned int".
Suggested-by: Thomas Gleixner
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
v2:
- Create this new patch to define PASID as "u
Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on next-20200612]
[cannot apply to iommu/next robh/for-next arm/for-next keystone/next
rockchip/for-next arm64/for-next/core shawnguo/for-next soc/for-next v5.7]
[if your
Hi Jerry,
On 2020/6/13 7:10, Jerry Snitselaar wrote:
Move Intel Kconfig and Makefile bits down into intel directory
with the rest of the Intel specific files.
Cc: Joerg Roedel
Cc: Lu Baolu
Thanks!
Reviewed-by: Lu Baolu
Best regards,
baolu
Signed-off-by: Jerry Snitselaar
---
drivers/
28 matches
Mail list logo
