Hi Alex,
Thanks for the report.
On 6/18/20 4:06 AM, Alex Williamson wrote:
On Sat, 16 May 2020 14:21:01 +0800
Lu Baolu wrote:
From: Tom Murphy
There's no need for the non-dma_ops path to keep track of IOVAs. The
whole point of the non-dma_ops path is that it allows the IOVAs to be
handled
From: Jean-Philippe Brucker
[ Upstream commit 52f3fab0067d6fa9e99c1b7f63265dd48ca76046 ]
Some SMMUv3 implementation embed the Perf Monitor Group Registers (PMCG)
inside the first 64kB region of the SMMU. Since PMCG are managed by a
separate driver, this layout causes resource reservation
On Thu, 11 Jun 2020 16:21:24 -0600, Jordan Crouse wrote:
> Every Qcom Adreno GPU has an embedded SMMU for its own use. These
> devices depend on unique features such as split pagetables,
> different stall/halt requirements and other settings. Identify them
> with a compatible string so that they
On Thu, 11 Jun 2020 20:10:29 +0900, Yoshihiro Shimoda wrote:
> Add support for r8a77961 (R-Car M3-W+).
>
> Signed-off-by: Yoshihiro Shimoda
> ---
> Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring
On Tue, 09 Jun 2020 15:40:19 -0400, Jonathan Marek wrote:
> Add compatible strings for sm8150 and sm8250 iommus to documentation.
>
> Signed-off-by: Jonathan Marek
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Rob Herring
On Wed, Jun 17, 2020 at 1:16 PM Eric Anholt wrote:
>
> On Thu, Apr 9, 2020 at 4:34 PM Jordan Crouse wrote:
> >
> > Refactor how address space initialization works. Instead of having the
> > address space function create the MMU object (and thus require separate but
> > equal functions for gpummu
On Thu, Apr 9, 2020 at 4:34 PM Jordan Crouse wrote:
>
> Refactor how address space initialization works. Instead of having the
> address space function create the MMU object (and thus require separate but
> equal functions for gpummu and iommu) use a single function and pass the
> MMU struct in.
On Sat, 16 May 2020 14:21:01 +0800
Lu Baolu wrote:
> From: Tom Murphy
>
> There's no need for the non-dma_ops path to keep track of IOVAs. The
> whole point of the non-dma_ops path is that it allows the IOVAs to be
> handled separately. The IOVA handling code removed in this patch is
>
On Wed, Jun 17, 2020 at 12:39 PM Luck, Tony wrote:
>
> > Is PASID in the uapi at all?
>
>
> $ grep pasid include/uapi/linux/iommu.h
> * @pasid: Process Address Space ID
> __u32 pasid;
> * @pasid: Process Address Space ID
> __u32 pasid;
> * @pasid: Process Address Space ID
>
Hi Greg, Christoph,
On Wed, Jun 17, 2020 at 12:31 AM Christoph Hellwig wrote:
>
> On Tue, Jun 16, 2020 at 12:27:35PM -0700, Rajat Jain wrote:
> > Need clarification. The flag "untrusted" is currently a part of
> > pci_dev struct, and is populated within the PCI subsystem.
>
> Yes, and that is
> Is PASID in the uapi at all?
$ grep pasid include/uapi/linux/iommu.h
* @pasid: Process Address Space ID
__u32 pasid;
* @pasid: Process Address Space ID
__u32 pasid;
* @pasid: Process Address Space ID
__u32 pasid;
* - If the PASID bit is set, the @pasid field is
On Wed, Jun 17, 2020 at 11:24 AM Fenghua Yu wrote:
>
> 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
The pull request you sent on Wed, 17 Jun 2020 09:27:16 +0200:
> git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.8-3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1b5044021070efa3259f3e9548dc35d1eb6aa844
Thank you!
--
Deet-doot-dot, I am a bot.
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:
-
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
From: Peter Zijlstra
The flag is defined for the task to identify if the task has a valid
PASID. Its initial value is 0 when the task is forked/cloned. It will
be used shortly.
Signed-off-by: Peter Zijlstra
Co-developed-by: Fenghua Yu
Signed-off-by: Fenghua Yu
---
v2:
- Add this patch to
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
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
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
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
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
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
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
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
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
---
v3:
- Change CONFIG_PCI_PASID to CONFIG_IOMMU_SUPPORT
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
"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.
On Wed, Jun 17, 2020 at 9:00 AM Robin Murphy wrote:
>
> Hi Jim,
>
> Thanks for taking this on!
Hi Robin,
>
> On 2020-06-16 21:55, Jim Quinlan wrote:
> > The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> > the use of single or multiple pfn offsets between cpu addrs and
[+ Will and Robin]
Hi Yi,
On Thu, Jun 11, 2020 at 05:15:21AM -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: Kevin Tian
> CC: Jacob Pan
> Cc: Alex Williamson
>
Hi Jim,
Thanks for taking this on!
On 2020-06-16 21:55, Jim Quinlan wrote:
The new field in struct device 'dma_pfn_offset_map' is used to facilitate
the use of single or multiple pfn offsets between cpu addrs and dma addrs.
It subsumes the role of dev->dma_pfn_offset -- a uniform offset.
Hi Matthias,
Thanks very much for your review.
On Wed, 2020-06-17 at 11:17 +0200, Matthias Brugger wrote:
>
> On 17/06/2020 05:00, Chao Hao wrote:
> > The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> > diagram).
> > If the larb's number is over 8, we use a sub_common
On 6/17/20 5:04 AM, Paul Menzel wrote:
Currently, Linux logs the two messages below.
[0.979142] pci :00:00.2: AMD-Vi: Extended features
(0xf77ef22294ada):
[0.979546] PPR NX GT IA GA PC GA_vAPIC
The log level of these lines differs though. The first one has level
On 17/06/2020 05:00, Chao Hao wrote:
> Add F_MMU_IN_ORDER_WR_EN definition in MISC_CTRL.
> In order to improve performance, we always disable STANDARD_AXI_MODE
> and IN_ORDER_WR_EN in MISC_CTRL.
>
> Change since v3:
The changelog should go below the '---' as we don't want this in the git
On Mon, Jun 15, 2020 at 09:55:57PM +0800, Zhangfei Gao wrote:
> Fix NULL pointer error if removing uacce's parent module during app's
> running. SIGBUS is already reported by do_page_fault, so uacce_vma_fault
> is not needed. If providing vma_fault, vmf->page has to be filled as well,
> required
On 17/06/2020 05:00, Chao Hao wrote:
> 1. Start from mt6779, INVLDT_SEL move to offset=0x2c, so we add
>REG_MMU_INV_SEL_GEN2 definition and mt6779 uses it.
> 2. Change PROTECT_PA_ALIGN from 128 byte to 256 byte.
> 3. For REG_MMU_CTRL_REG register, we only need to change bit[2:0],
>
On 17/06/2020 05:00, Chao Hao wrote:
> Some platforms(ex: mt6779) have a new register called by REG_MMU_WR_LEN
> to improve performance.
> This patch add this register definition.
Please be more specific what this register is about.
>
> Signed-off-by: Chao Hao
> ---
>
On 17/06/2020 05:00, Chao Hao wrote:
> The max larb number that a iommu HW support is 8(larb0~larb7 in the below
> diagram).
> If the larb's number is over 8, we use a sub_common for merging
> several larbs into one larb. At this case, we will extend larb_id:
> bit[11:9] means common-id;
>
On 17/06/2020 05:00, Chao Hao wrote:
> For mt6779, MMU_INV_SEL register's offset is changed from
> 0x38 to 0x2c, so we can put inv_sel_reg in the plat_data to
> use it.
> In addition, we renamed it to REG_MMU_INV_SEL_GEN1 and use it
> before mt6779.
>
> Change since v3:
> 1. Fix coding style
>
On 17/06/2020 05:00, Chao Hao wrote:
> For iommu offset=0x48 register, only the previous mt8173/mt8183 use the
> name STANDARD_AXI_MODE, all the latest SoC extend the register more
> feature by different bits, for example: axi_mode, in_order_en, coherent_en
> and so on. So rename
On Tue, Jun 16, 2020 at 04:23:46PM -0700, Fenghua Yu wrote:
> Hi, Peter,
>
> On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote:
> > On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
> >
> > > Or do you suggest to add a random new flag in struct thread_info instead
> > > of
> From: Liu, Yi L
> Sent: Wednesday, June 17, 2020 2:20 PM
>
> > From: Jacob Pan
> > Sent: Tuesday, June 16, 2020 11:22 PM
> >
> > On Thu, 11 Jun 2020 17:27:27 -0700
> > Jacob Pan wrote:
> >
> > > >
> > > > But then I thought it even better if VFIO leaves the entire
> > > > copy_from_user() to
On Tue, Jun 16, 2020 at 12:27:35PM -0700, Rajat Jain wrote:
> Need clarification. The flag "untrusted" is currently a part of
> pci_dev struct, and is populated within the PCI subsystem.
Yes, and that is the problem.
>
> 1) Is your suggestion to move this flag as well as the attribute to
>
The following changes since commit abfbb29297c27e3f101f348dc9e467b0fe70f919:
Merge tag 'rproc-v5.8' of
git://git.kernel.org/pub/scm/linux/kernel/git/andersson/remoteproc (2020-06-08
13:01:08 -0700)
are available in the Git repository at:
git://git.infradead.org/users/hch/dma-mapping.git
On Tue, Jun 16, 2020 at 01:02:11PM +0100, Vladimir Murzin wrote:
> LGTM. Should it go stable as well?
I think it will be picked up automatically eventually due to the Fixes
tag.
___
iommu mailing list
iommu@lists.linux-foundation.org
> From: Stefan Hajnoczi
> Sent: Monday, June 15, 2020 5:41 PM
> On Thu, Jun 11, 2020 at 05:15:33AM -0700, Liu Yi L wrote:
>
> > From: Eric Auger
> >
> > The VFIO API was enhanced to support nested stage control: a bunch of
> > new iotcls and usage guideline.
> >
> > Let's document the process to
> From: Jacob Pan
> Sent: Tuesday, June 16, 2020 11:22 PM
>
> On Thu, 11 Jun 2020 17:27:27 -0700
> Jacob Pan wrote:
>
> > >
> > > But then I thought it even better if VFIO leaves the entire
> > > copy_from_user() to the layer consuming it.
> > >
> > OK. Sounds good, that was what Kevin
46 matches
Mail list logo
