Re: [PATCH 1/1] iommu/vt-d: Fix build error of pasid_enable_wpe() with !X86

2021-04-11 Thread Randy Dunlap
On 4/10/21 11:23 PM, Lu Baolu wrote:
> Commit f68c7f539b6e9 ("iommu/vt-d: Enable write protect for supervisor
> SVM") added pasid_enable_wpe() which hit below compile error with !X86.
> 
> ../drivers/iommu/intel/pasid.c: In function 'pasid_enable_wpe':
> ../drivers/iommu/intel/pasid.c:554:22: error: implicit declaration of 
> function 'read_cr0' [-Werror=implicit-function-declaration]
>   554 |  unsigned long cr0 = read_cr0();
>   |  ^~~~
> In file included from ../include/linux/build_bug.h:5,
>  from ../include/linux/bits.h:22,
>  from ../include/linux/bitops.h:6,
>  from ../drivers/iommu/intel/pasid.c:12:
> ../drivers/iommu/intel/pasid.c:557:23: error: 'X86_CR0_WP' undeclared (first 
> use in this function)
>   557 |  if (unlikely(!(cr0 & X86_CR0_WP))) {
>   |   ^~
> ../include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
>78 | # define unlikely(x) __builtin_expect(!!(x), 0)
>   |  ^
> ../drivers/iommu/intel/pasid.c:557:23: note: each undeclared identifier is 
> reported only once for each function it appears in
>   557 |  if (unlikely(!(cr0 & X86_CR0_WP))) {
>   |   ^~
> ../include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
>78 | # define unlikely(x) __builtin_expect(!!(x), 0)
>   |
> 
> Add the missing dependency.
> 
> Cc: Sanjay Kumar 
> Cc: Jacob Pan 
> Cc: Randy Dunlap 
> Reported-by: kernel test robot 
> Reported-by: Randy Dunlap 
> Fixes: f68c7f539b6e9 ("iommu/vt-d: Enable write protect for supervisor SVM")
> Signed-off-by: Lu Baolu 

Acked-by: Randy Dunlap  # build-tested


Thanks.

> ---
>  drivers/iommu/intel/pasid.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c
> index 477b2e1d303c..72646bafc52f 100644
> --- a/drivers/iommu/intel/pasid.c
> +++ b/drivers/iommu/intel/pasid.c
> @@ -551,6 +551,7 @@ static void pasid_flush_caches(struct intel_iommu *iommu,
>  
>  static inline int pasid_enable_wpe(struct pasid_entry *pte)
>  {
> +#ifdef CONFIG_X86
>   unsigned long cr0 = read_cr0();
>  
>   /* CR0.WP is normally set but just to be sure */
> @@ -558,6 +559,7 @@ static inline int pasid_enable_wpe(struct pasid_entry 
> *pte)
>   pr_err_ratelimited("No CPU write protect!\n");
>   return -EINVAL;
>   }
> +#endif
>   pasid_set_wpe(pte);
>  
>   return 0;
> 


-- 
~Randy

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: linux-next: Tree for Apr 9 (drivers/iommu/intel/pasid.c)

2021-04-10 Thread Randy Dunlap
On 4/9/21 4:51 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20210408:
> 
> New trees: iio, iio-fixes
> 

on ia64: (not X86)

(from a 01.org kernel config file)


../drivers/iommu/intel/pasid.c: In function 'pasid_enable_wpe':
../drivers/iommu/intel/pasid.c:554:22: error: implicit declaration of function 
'read_cr0' [-Werror=implicit-function-declaration]
  554 |  unsigned long cr0 = read_cr0();
  |  ^~~~
In file included from ../include/linux/build_bug.h:5,
 from ../include/linux/bits.h:22,
 from ../include/linux/bitops.h:6,
 from ../drivers/iommu/intel/pasid.c:12:
../drivers/iommu/intel/pasid.c:557:23: error: 'X86_CR0_WP' undeclared (first 
use in this function)
  557 |  if (unlikely(!(cr0 & X86_CR0_WP))) {
  |   ^~
../include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
   78 | # define unlikely(x) __builtin_expect(!!(x), 0)
  |  ^
../drivers/iommu/intel/pasid.c:557:23: note: each undeclared identifier is 
reported only once for each function it appears in
  557 |  if (unlikely(!(cr0 & X86_CR0_WP))) {
  |   ^~
../include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
   78 | # define unlikely(x) __builtin_expect(!!(x), 0)
  |  ^



-- 
~Randy
Reported-by: Randy Dunlap 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 2/2] iommu: add Unisoc iommu basic driver

2021-02-03 Thread Randy Dunlap
On 2/3/21 1:07 AM, Chunyan Zhang wrote:
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 192ef8f61310..99e7712f3903 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -408,4 +408,16 @@ config VIRTIO_IOMMU
>  
> Say Y here if you intend to run this kernel as a guest.
>  
> +config SPRD_IOMMU
> + tristate "Unisoc IOMMU Support"
> + depends on ARCH_SPRD || COMPILE_TEST
> + select IOMMU_API
> + help
> +   Support for IOMMU on Unisoc's SoCs, this iommu can be used by

s/iommu/IOMMU/ please

> +   Unisoc's multimedia devices, such as display, Image codec(jpeg)
> +   and a few signal processors, including VSP(video), GSP(graphic),
> +   ISP(image), and CPP(camera pixel processor), etc.
> +
> +   Say Y here if you want to use the multimedia devices listed above.


-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/1] iommu/vt-d: Fix compile error [-Werror=implicit-function-declaration]

2021-01-30 Thread Randy Dunlap
On 1/30/21 7:19 AM, Lu Baolu wrote:
> trace_qi_submit() could be used when interrupt remapping is supported,
> but DMA remapping is not. In this case, the following compile error
> occurs.
> 
> ../drivers/iommu/intel/dmar.c: In function 'qi_submit_sync':
> ../drivers/iommu/intel/dmar.c:1311:3: error: implicit declaration of function 
> 'trace_qi_submit';
>   did you mean 'ftrace_nmi_exit'? [-Werror=implicit-function-declaration]
>trace_qi_submit(iommu, desc[i].qw0, desc[i].qw1,
>^~~
>ftrace_nmi_exit
> 
> Fixes: f2dd871799ba5 ("iommu/vt-d: Add qi_submit trace event")
> Reported-by: kernel test robot 
> Reported-by: Randy Dunlap 
> Signed-off-by: Lu Baolu 
> ---
>  drivers/iommu/intel/Makefile   | 2 +-
>  drivers/iommu/intel/iommu.c| 1 -
>  include/trace/events/intel_iommu.h | 2 --
>  3 files changed, 1 insertion(+), 4 deletions(-)

Acked-by: Randy Dunlap  # build-tested


Thanks.

-- 
~Randy

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


linux-next-20210129: drivers/iommu/intel/dmar.c

2021-01-29 Thread Randy Dunlap
on x86_64:

../drivers/iommu/intel/dmar.c: In function 'qi_submit_sync':
../drivers/iommu/intel/dmar.c:1311:3: error: implicit declaration of function 
'trace_qi_submit'; did you mean 'ftrace_nmi_exit'? 
[-Werror=implicit-function-declaration]
   trace_qi_submit(iommu, desc[i].qw0, desc[i].qw1,
   ^~~
   ftrace_nmi_exit

Full randconfig file is attached.

-- 
~Randy
Reported-by: Randy Dunlap 



config-r7511.gz
Description: application/gzip
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 01/13] x86: Secure Launch Kconfig

2020-09-24 Thread Randy Dunlap
On 9/24/20 7:58 AM, Ross Philipson wrote:
> Initial bits to bring in Secure Launch functionality. Add Kconfig
> options for compiling in/out the Secure Launch code.
> 
> Signed-off-by: Ross Philipson 

Hi,
from Documentation/process/coding-style.rst:

Lines under a ``config`` definition
are indented with one tab, while help text is indented an additional two
spaces.

> ---
>  arch/x86/Kconfig | 36 
>  1 file changed, 36 insertions(+)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 7101ac6..8957981 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1968,6 +1968,42 @@ config EFI_MIXED
>  
>  If unsure, say N.
>  
> +config SECURE_LAUNCH
> + bool "Secure Launch support"
> + default n
> + depends on X86_64
> + help
> +The Secure Launch feature allows a kernel to be loaded
> +directly through an Intel TXT measured launch. Intel TXT
> +establishes a Dynamic Root of Trust for Measurement (DRTM)
> +where the CPU measures the kernel image. This feature then
> +continues the measurement chain over kernel configuration
> +information and init images.
> +
> +choice
> + prompt "Select Secure Launch Algorithm for TPM2"
> + depends on SECURE_LAUNCH
> +
> +config SECURE_LAUNCH_SHA1
> + bool "Secure Launch TPM1 SHA1"
> + help
> +When using Secure Launch and TPM1 is present, use SHA1 hash
> +algorithm for measurements.
> +
> +config SECURE_LAUNCH_SHA256
> + bool "Secure Launch TPM2 SHA256"
> + help
> +When using Secure Launch and TPM2 is present, use SHA256 hash
> +algorithm for measurements.
> +
> +config SECURE_LAUNCH_SHA512
> + bool "Secure Launch TPM2 SHA512"
> + help
> +When using Secure Launch and TPM2 is present, use SHA512 hash
> +algorithm for measurements.
> +
> +endchoice
> +


thanks.
-- 
~Randy

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v9 1/7] docs: IOMMU user API

2020-09-16 Thread Randy Dunlap
On 9/11/20 2:57 PM, 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 userspace in general.
> 
> This document is intended to clarify the UAPI design and usage. The
> mechanics of how future extensions should be achieved are also covered
> in this documentation.
> 
> Reviewed-by: Eric Auger 
> Signed-off-by: Liu Yi L 
> Signed-off-by: Jacob Pan 
> ---
>  Documentation/userspace-api/iommu.rst | 211 
> ++
>  MAINTAINERS   |   1 +
>  2 files changed, 212 insertions(+)
>  create mode 100644 Documentation/userspace-api/iommu.rst

Hi,
I have a few edit changes for you below:


> diff --git a/Documentation/userspace-api/iommu.rst 
> b/Documentation/userspace-api/iommu.rst
> new file mode 100644
> index ..1e68e8f05bb3
> --- /dev/null
> +++ b/Documentation/userspace-api/iommu.rst
> @@ -0,0 +1,211 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +.. iommu:
> +
> +=
> +IOMMU Userspace API
> +=
> +
> +IOMMU UAPI is used for virtualization cases where communications are
> +needed between physical and virtual IOMMU drivers. For baremetal
> +usage, the IOMMU is a system device which does not need to communicate
> +with user space directly.

userspace

for consistency

> +
> +The primary use cases are guest Shared Virtual Address (SVA) and
> +guest IO virtual address (IOVA), wherin the vIOMMU implementation

wherein

> +relies on the physical IOMMU and for this reason requires interactions
> +with the host driver.
> +
> +.. contents:: :local:
> +
> +Functionalities
> +===
> +Communications of user and kernel involve both directions. The
> +supported user-kernel APIs are as follows:
> +
> +1. Alloc/Free PASID
> +2. Bind/Unbind guest PASID (e.g. Intel VT-d)
> +3. Bind/Unbind guest PASID table (e.g. ARM SMMU)
> +4. Invalidate IOMMU caches upon guest requests
> +5. Report errors to the guest and serve page requests
> +
> +Requirements
> +
> +The IOMMU UAPIs are generic and extensible to meet the following
> +requirements:
> +
> +1. Emulated and para-virtualised vIOMMUs
> +2. Multiple vendors (Intel VT-d, ARM SMMU, etc.)
> +3. Extensions to the UAPI shall not break existing user space

  userspace

> +
> +Interfaces
> +==
> +Although the data structures defined in IOMMU UAPI are self-contained,
> +there is no user API functions introduced. Instead, IOMMU UAPI is

   there are no

> +designed to work with existing user driver frameworks such as VFIO.
> +
> +Extension Rules & Precautions
> +-
> +When IOMMU UAPI gets extended, the data structures can *only* be
> +modified in two ways:
> +
> +1. Adding new fields by re-purposing the padding[] field. No size change.
> +2. Adding new union members at the end. May increase the structure sizes.
> +
> +No new fields can be added *after* the variable sized union in that it
> +will break backward compatibility when offset moves. A new flag must
> +be introduced whenever a change affects the structure using either
> +method. The IOMMU driver processes the data based on flags which
> +ensures backward compatibility.
> +
> +Version field is only reserved for the unlikely event of UAPI upgrade
> +at its entirety.
> +
> +It's *always* the caller's responsibility to indicate the size of the
> +structure passed by setting argsz appropriately.
> +Though at the same time, argsz is user provided data which is not
> +trusted. The argsz field allows the user app to indicate how much data
> +it is providing, it's still the kernel's responsibility to validate

 providing;

> +whether it's correct and sufficient for the requested operation.
> +
> +Compatibility Checking
> +--
> +When IOMMU UAPI extension results in some structure size increase,
> +IOMMU UAPI code shall handle the following cases:
> +
> +1. User and kernel has exact size match
> +2. An older user with older kernel header (smaller UAPI size) running on a
> +   newer kernel (larger UAPI size)
> +3. A newer user with newer kernel header (larger UAPI size) running
> +   on an older kernel.
> +4. A malicious/misbehaving user pass illegal/invalid size but within

   passing

> +   range. The data may contain garbage.
> +
> +Feature Checking
> +
> +While launching a guest with vIOMMU, it is strongly advised to check
> +the compatibility upfront, as some subsequent errors happening during
> +vIOMMU operation, such as cache invalidation failures cannot be nicely> 
> +escaladated to the guest due to IOMMU specifications. This can lead to

   escalated

> +catastrophic failures for the users.
> +
> +User applications such as QEMU are 

Re: [PATCH v7 3/9] docs: x86: Add documentation for SVA (Shared Virtual Addressing)

2020-09-05 Thread Randy Dunlap
Hi,

I'll add a few edits other than those that Borislav made.
(nice review job, BP)


On 8/27/20 8:06 AM, Fenghua Yu wrote:
> 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-off-by: Fenghua Yu 
> Reviewed-by: Tony Luck 
> ---
> v7:
> - Change the doc for updating PASID by IPI and context switch (Andy).
> 
> v3:
> - Replace deprecated intel_svm_bind_mm() by iommu_sva_bind_mm() (Baolu)
> - Fix a couple of typos (Baolu)
> 
> v2:
> - Fix the doc format and add the doc in toctree (Thomas)
> - Modify the doc for better description (Thomas, Tony, Dave)
> 
>  Documentation/x86/index.rst |   1 +
>  Documentation/x86/sva.rst   | 254 
>  2 files changed, 255 insertions(+)
>  create mode 100644 Documentation/x86/sva.rst


> diff --git a/Documentation/x86/sva.rst b/Documentation/x86/sva.rst
> new file mode 100644
> index ..6e7ac565e127
> --- /dev/null
> +++ b/Documentation/x86/sva.rst
> @@ -0,0 +1,254 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +===
> +Shared Virtual Addressing (SVA) with ENQCMD
> +===
> +
> +Background
> +==
> +

...

> +
> +Shared Hardware Workqueues
> +==
> +
> +Unlike Single Root I/O Virtualization (SRIOV), Scalable IOV (SIOV) permits
> +the use of Shared Work Queues (SWQ) by both applications and Virtual
> +Machines (VM's). This allows better hardware utilization vs. hard
> +partitioning resources that could result in under utilization. In order to
> +allow the hardware to distinguish the context for which work is being
> +executed in the hardware by SWQ interface, SIOV uses Process Address Space
> +ID (PASID), which is a 20bit number defined by the PCIe SIG.

  20-bit

> +
> +PASID value is encoded in all transactions from the device. This allows the
> +IOMMU to track I/O on a per-PASID granularity in addition to using the PCIe
> +Resource Identifier (RID) which is the Bus/Device/Function.
> +
> +
> +ENQCMD
> +==
> +

...

> +
> +Process Address Space Tagging
> +=
> +

...

> +
> +PASID Management
> +
> +

...

> +
> +Relationships
> +=
> +
> + * Each process has many threads, but only one PASID

   (end with) PASID.

> + * Devices have a limited number (~10's to 1000's) of hardware
> +   workqueues and each portal maps down to a single workqueue.
> +   The device driver manages allocating hardware workqueues.
> + * A single mmap() maps a single hardware workqueue as a "portal"

 (end with)  .

> + * For each device with which a process interacts, there must be
> +   one or more mmap()'d portals.
> + * Many threads within a process can share a single portal to access
> +   a single device.
> + * Multiple processes can separately mmap() the same portal, in
> +   which case they still share one device hardware workqueue.
> + * The single process-wide PASID is used by all threads to interact
> +   with all devices.  There is not, for instance, a PASID for each
> +   thread or each thread<->device pair.
> +
> +FAQ
> +===
> +
> +* What is SVA/SVM?
> +
> +Shared Virtual Addressing (SVA) permits I/O hardware and the processor to
> +work in the same address space. In short, sharing the address space. Some
> +call it Shared Virtual Memory (SVM), but Linux community wanted to avoid

waned to avoid 
confusing

> +it with Posix Shared Memory and Secure Virtual Machines which were terms

   POSIX

> +already in circulation.
> +
> +* What is a PASID?
> +
> +A Process Address Space ID (PASID) is a PCIe-defined TLP Prefix. A PASID is

ah, BP already commented about using acronyms to define acronyms.  :)

> +a 20 bit number allocated and managed by the OS. PASID is included in all

 20-bit

> +transactions between the platform and the device.
> +
> +* How are shared work queues different?
> +
> +Traditionally to allow user space applications interact with hardware,
> +there is a separate instance required per process. For example, consider
> +doorbells as a mechanism of informing hardware about work to process. Each
> +doorbell is required to be spaced 4k (or page-size) apart for process
> +isolation. This requires hardware to provision that space and reserve in

 reserve it in

> +MMIO. This doesn't scale as the number of threads becomes quite large. The
> +hardware also manages the queue depth for Shared Work Queues (SWQ), and
> +consumers don't need to track queue depth. If 

Re: [PATCH v2 3/9] iommu/ioasid: Introduce ioasid_set APIs

2020-08-24 Thread Randy Dunlap
On 8/24/20 11:28 AM, Jean-Philippe Brucker wrote:
>> +/**
>> + * struct ioasid_set - Meta data about ioasid_set
>> + * @type:   Token types and other features
> nit: doesn't follow struct order
> 
>> + * @token:  Unique to identify an IOASID set
>> + * @xa: XArray to store ioasid_set private IDs, can be used for
>> + *  guest-host IOASID mapping, or just a private IOASID namespace.
>> + * @quota:  Max number of IOASIDs can be allocated within the set
>> + * @nr_ioasids  Number of IOASIDs currently allocated in the set

 * @nr_ioasids: Number of IOASIDs currently allocated in the set

>> + * @sid:ID of the set
>> + * @ref:Reference count of the users
>> + */
>>  struct ioasid_set {
>> -int dummy;
>> +void *token;
>> +struct xarray xa;
>> +int type;
>> +int quota;
>> +int nr_ioasids;
>> +int sid;
>> +refcount_t ref;
>> +struct rcu_head rcu;
>>  };


-- 
~Randy

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 3/9] iommu/ioasid: Introduce ioasid_set APIs

2020-08-24 Thread Randy Dunlap
On 8/24/20 11:28 AM, Jean-Philippe Brucker wrote:
>> +/**
>> + * struct ioasid_data - Meta data about ioasid
>> + *
>> + * @id: Unique ID
>> + * @users   Number of active users
>> + * @state   Track state of the IOASID
>> + * @set Meta data of the set this IOASID belongs to
>> + * @private Private data associated with the IOASID
>> + * @rcu For free after RCU grace period
> nit: it would be nicer to follow the struct order

and use a ':' after each struct member name, as is done for @id:

-- 
~Randy

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v7 1/3] dma-contiguous: provide the ability to reserve per-numa CMA

2020-08-21 Thread Randy Dunlap
On 8/21/20 4:33 AM, Barry Song wrote:
> ---
>  -v7: with respect to Will's comments
>  * move to use for_each_online_node
>  * add description if users don't specify pernuma_cma
>  * provide default value for CONFIG_DMA_PERNUMA_CMA
> 
>  .../admin-guide/kernel-parameters.txt |  11 ++
>  include/linux/dma-contiguous.h|   6 ++
>  kernel/dma/Kconfig|  11 ++
>  kernel/dma/contiguous.c   | 100 --
>  4 files changed, 118 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index bdc1f33fd3d1..c609527fc35a 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -599,6 +599,17 @@
>   altogether. For more information, see
>   include/linux/dma-contiguous.h
>  
> + pernuma_cma=nn[MG]
> + [ARM64,KNL]
> + Sets the size of kernel per-numa memory area for
> + contiguous memory allocations. A value of 0 disables
> + per-numa CMA altogether. And If this option is not
> + specificed, the default value is 0.
> + With per-numa CMA enabled, DMA users on node nid will
> + first try to allocate buffer from the pernuma area
> + which is located in node nid, if the allocation fails,
> + they will fallback to the global default memory area.
> +

Entries in kernel-parameters.txt are supposed to be in alphabetical order
but this one is not.  If you want to keep it near the cma= entry, you can
rename it like Mike suggested.  Otherwise it needs to be moved.


>   cmo_free_hint=  [PPC] Format: { yes | no }
>   Specify whether pages are marked as being inactive
>   when they are freed.  This is used in CMO environments



-- 
~Randy

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v6 1/2] dma-contiguous: provide the ability to reserve per-numa CMA

2020-08-20 Thread Randy Dunlap
On 8/20/20 7:26 PM, Barry Song wrote:
> 
> 
> Cc: Jonathan Cameron 
> Cc: Christoph Hellwig 
> Cc: Marek Szyprowski 
> Cc: Will Deacon 
> Cc: Robin Murphy 
> Cc: Ganapatrao Kulkarni 
> Cc: Catalin Marinas 
> Cc: Nicolas Saenz Julienne 
> Cc: Steve Capper 
> Cc: Andrew Morton 
> Cc: Mike Rapoport 
> Signed-off-by: Barry Song 
> ---
>  v6: rebase on top of 5.9-rc1;
>  doc cleanup
> 
>  .../admin-guide/kernel-parameters.txt |   9 ++
>  include/linux/dma-contiguous.h|   6 ++
>  kernel/dma/Kconfig|  10 ++
>  kernel/dma/contiguous.c   | 100 --
>  4 files changed, 115 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index bdc1f33fd3d1..3f33b89aeab5 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -599,6 +599,15 @@
>   altogether. For more information, see
>   include/linux/dma-contiguous.h
>  
> + pernuma_cma=nn[MG]

memparse() allows any one of these suffixes: K, M, G, T, P, E
and nothing in the option parsing function cares what suffix is used...

> + [ARM64,KNL]
> + Sets the size of kernel per-numa memory area for
> + contiguous memory allocations. A value of 0 disables
> + per-numa CMA altogether. DMA users on node nid will
> + first try to allocate buffer from the pernuma area
> + which is located in node nid, if the allocation fails,
> + they will fallback to the global default memory area.
> +
>   cmo_free_hint=  [PPC] Format: { yes | no }
>   Specify whether pages are marked as being inactive
>   when they are freed.  This is used in CMO environments

> diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
> index cff7e60968b9..89b95f10e56d 100644
> --- a/kernel/dma/contiguous.c
> +++ b/kernel/dma/contiguous.c
> @@ -69,6 +69,19 @@ static int __init early_cma(char *p)
>  }
>  early_param("cma", early_cma);
>  
> +#ifdef CONFIG_DMA_PERNUMA_CMA
> +
> +static struct cma *dma_contiguous_pernuma_area[MAX_NUMNODES];
> +static phys_addr_t pernuma_size_bytes __initdata;

why phys_addr_t? couldn't it just be unsigned long long?

OK, so cma_declare_contiguous_nid() uses phys_addr_t. Fine.

> +
> +static int __init early_pernuma_cma(char *p)
> +{
> + pernuma_size_bytes = memparse(p, );
> + return 0;
> +}
> +early_param("pernuma_cma", early_pernuma_cma);
> +#endif
> +
>  #ifdef CONFIG_CMA_SIZE_PERCENTAGE
>  
>  static phys_addr_t __init __maybe_unused cma_early_percent_memory(void)
> @@ -96,6 +109,34 @@ static inline __maybe_unused phys_addr_t 
> cma_early_percent_memory(void)
>  
>  #endif
>  
> +#ifdef CONFIG_DMA_PERNUMA_CMA
> +void __init dma_pernuma_cma_reserve(void)
> +{
> + int nid;
> +
> + if (!pernuma_size_bytes)
> + return;
> +
> + for_each_node_state(nid, N_ONLINE) {
> + int ret;
> + char name[20];
> + struct cma **cma = _contiguous_pernuma_area[nid];
> +
> + snprintf(name, sizeof(name), "pernuma%d", nid);
> + ret = cma_declare_contiguous_nid(0, pernuma_size_bytes, 0, 0,
> +  0, false, name, cma, nid);
> + if (ret) {
> + pr_warn("%s: reservation failed: err %d, node %d", 
> __func__,
> + ret, nid);
> + continue;
> + }
> +
> + pr_debug("%s: reserved %llu MiB on node %d\n", __func__,
> + (unsigned long long)pernuma_size_bytes / SZ_1M, nid);

Conversely, if you want to leave pernuma_size_bytes as phys_addr_t,
you should use %pa (or %pap) to print it.

> + }
> +}
> +#endif



-- 
~Randy

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

2020-04-08 Thread Randy Dunlap
On 4/8/20 8:36 AM, Christoph Hellwig wrote:
> On Wed, Apr 08, 2020 at 08:15:19AM -0700, Matthew Wilcox wrote:
>  config ZSMALLOC_PGTABLE_MAPPING
>   bool "Use page table mapping to access object in zsmalloc"
> - depends on ZSMALLOC
> + depends on ZSMALLOC=y

 It's a bool so this shouldn't matter... not needed.
>>>
>>> My mm/Kconfig has:
>>>
>>> config ZSMALLOC
>>> tristate "Memory allocator for compressed pages"
>>> depends on MMU
>>>
>>> which I think means it can be modular, no?
>>
>> Randy means that ZSMALLOC_PGTABLE_MAPPING is a bool, so I think hch's patch
>> is wrong ... if ZSMALLOC is 'm' then ZSMALLOC_PGTABLE_MAPPING would become
>> 'n' instead of 'y'.
> 
> In Linus' tree you can select PGTABLE_MAPPING=y with ZSMALLOC=m,
> and that fits my understanding of the kbuild language.  With this
> patch I can't anymore.
> 

Makes sense. thanks.

-- 
~Randy

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

2020-04-08 Thread Randy Dunlap
On 4/8/20 8:15 AM, Matthew Wilcox wrote:
> On Wed, Apr 08, 2020 at 05:12:03PM +0200, Peter Zijlstra wrote:
>> On Wed, Apr 08, 2020 at 08:01:00AM -0700, Randy Dunlap wrote:
>>> Hi,
>>>
>>> On 4/8/20 4:59 AM, Christoph Hellwig wrote:
>>>> diff --git a/mm/Kconfig b/mm/Kconfig
>>>> index 36949a9425b8..614cc786b519 100644
>>>> --- a/mm/Kconfig
>>>> +++ b/mm/Kconfig
>>>> @@ -702,7 +702,7 @@ config ZSMALLOC
>>>>  
>>>>  config ZSMALLOC_PGTABLE_MAPPING
>>>>bool "Use page table mapping to access object in zsmalloc"
>>>> -  depends on ZSMALLOC
>>>> +  depends on ZSMALLOC=y
>>>
>>> It's a bool so this shouldn't matter... not needed.
>>
>> My mm/Kconfig has:
>>
>> config ZSMALLOC
>>  tristate "Memory allocator for compressed pages"
>>  depends on MMU
>>
>> which I think means it can be modular, no?

ack. I misread it.

> Randy means that ZSMALLOC_PGTABLE_MAPPING is a bool, so I think hch's patch
> is wrong ... if ZSMALLOC is 'm' then ZSMALLOC_PGTABLE_MAPPING would become
> 'n' instead of 'y'.

sigh, I wish that I had meant that. :)

thanks.

-- 
~Randy

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc

2020-04-08 Thread Randy Dunlap
Hi,

On 4/8/20 4:59 AM, Christoph Hellwig wrote:
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 36949a9425b8..614cc786b519 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -702,7 +702,7 @@ config ZSMALLOC
>  
>  config ZSMALLOC_PGTABLE_MAPPING
>   bool "Use page table mapping to access object in zsmalloc"
> - depends on ZSMALLOC
> + depends on ZSMALLOC=y

It's a bool so this shouldn't matter... not needed.

>   help
> By default, zsmalloc uses a copy-based object mapping method to
> access allocations that span two pages. However, if a particular


-- 
~Randy

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 09/28] mm: rename CONFIG_PGTABLE_MAPPING to CONFIG_ZSMALLOC_PGTABLE_MAPPING

2020-04-08 Thread Randy Dunlap
On 4/8/20 4:59 AM, Christoph Hellwig wrote:
> Rename the Kconfig variable to clarify the scope.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/arm/configs/omap2plus_defconfig | 2 +-
>  include/linux/zsmalloc.h | 2 +-
>  mm/Kconfig   | 2 +-
>  mm/zsmalloc.c| 8 
>  4 files changed, 7 insertions(+), 7 deletions(-)
> 

Looks good. Thanks.

Acked-by: Randy Dunlap 


-- 
~Randy

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dma-mapping: mark dma_alloc_need_uncached as __always_inline

2019-07-08 Thread Randy Dunlap
On 7/8/19 12:57 PM, Christoph Hellwig wrote:
> Without the __always_inline at least i386 configs that have
> CONFIG_OPTIMIZE_INLINING set seem fail to inline
> dma_alloc_need_uncached, leading to a linker error because of
> undefined symbols.
> 
> Reported-by: Randy Dunlap 
> Signed-off-by: Christoph Hellwig 

Acked-by: Randy Dunlap  # build-tested

Thanks.

> ---
>  include/linux/dma-noncoherent.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/dma-noncoherent.h b/include/linux/dma-noncoherent.h
> index 53ee36ecdf37..3813211a9aad 100644
> --- a/include/linux/dma-noncoherent.h
> +++ b/include/linux/dma-noncoherent.h
> @@ -23,7 +23,7 @@ static inline bool dev_is_dma_coherent(struct device *dev)
>  /*
>   * Check if an allocation needs to be marked uncached to be coherent.
>   */
> -static inline bool dma_alloc_need_uncached(struct device *dev,
> +static __always_inline bool dma_alloc_need_uncached(struct device *dev,
>   unsigned long attrs)
>  {
>   if (dev_is_dma_coherent(dev))
> 


-- 
~Randy


Re: linux-next: Tree for Jul 5 (dma)

2019-07-05 Thread Randy Dunlap
On 7/5/19 3:30 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20190704:
> 

on i386:

ld: kernel/dma/direct.o: in function `dma_direct_alloc':
direct.c:(.text+0x1658): undefined reference to `arch_dma_alloc'
ld: kernel/dma/direct.o: in function `dma_direct_free':
direct.c:(.text+0x1704): undefined reference to `arch_dma_free'

Full randconfig file is attached.

-- 
~Randy
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 5.2.0-rc7 Kernel Configuration
#

#
# Compiler: gcc (SUSE Linux) 4.8.5
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=40805
CONFIG_CLANG_VERSION=0
CONFIG_CC_CAN_LINK=y
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_WARN_MAYBE_UNINITIALIZED=y
CONFIG_CC_DISABLE_WARN_MAYBE_UNINITIALIZED=y
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
# CONFIG_HEADER_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_USELIB is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_SIM=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
# end of IRQ subsystem

CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_ARCH_CLOCKSOURCE_INIT=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
# end of Timers subsystem

# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
CONFIG_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_SCHED_AVG_IRQ=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_PSI is not set
# end of CPU/Task time and stats accounting

# CONFIG_CPU_ISOLATION is not set

#
# RCU Subsystem
#
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FAST_NO_HZ is not set
# CONFIG_RCU_BOOST is not set
CONFIG_RCU_NOCB_CPU=y
# end of RCU Subsystem

# CONFIG_IKCONFIG is not set
CONFIG_IKHEADERS=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y

#
# Scheduler features
#
# end of Scheduler features

CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_KMEM=y
# CONFIG_BLK_CGROUP is not set
# CONFIG_CGROUP_SCHED is not set
# CONFIG_CGROUP_PIDS is not set
# CONFIG_CGROUP_RDMA is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CPUSETS is not set
CONFIG_CGROUP_DEVICE=y
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_CGROUP_PERF=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
CONFIG_CHECKPOINT_RESTORE=y
# CONFIG_SCHED_AUTOGROUP is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_SYSFS_DEPRECATED_V2 is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_RD_GZIP is not set
# CONFIG_RD_BZIP2 is not set
CONFIG_RD_LZMA=y
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_MULTIUSER=y
# CONFIG_SGETMASK_SYSCALL is not set
# CONFIG_SYSFS_SYSCALL is not set
CONFIG_FHANDLE=y
CONFIG_POSIX_TIMERS=y
CONFIG_PRINTK=y
CONFIG_PRINTK_NMI=y
CONFIG_BUG=y
CONFIG_PCSPKR_PLATFORM=y
# CONFIG_BASE_FULL is not set
CONFIG_FUTEX=y
CONFIG_FUTEX_PI=y
CONFIG_EPOLL=y
# CONFIG_SIGNALFD is not set
# CONFIG_TIMERFD is not set
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_IO_URING is not set
# CONFIG_ADVISE_SYSCALLS is not set
CONFIG_MEMBARRIER=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y

Re: [RFC PATCH v3 11/21] x86/watchdog/hardlockup: Add an HPET-based hardlockup detector

2019-05-14 Thread Randy Dunlap
On 5/14/19 7:02 AM, Ricardo Neri wrote:
> diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
> index 15d0fbe27872..376a5db81aec 100644
> --- a/arch/x86/Kconfig.debug
> +++ b/arch/x86/Kconfig.debug
> @@ -169,6 +169,17 @@ config IOMMU_LEAK
>  config HAVE_MMIOTRACE_SUPPORT
>   def_bool y
>  
> +config X86_HARDLOCKUP_DETECTOR_HPET
> + bool "Use HPET Timer for Hard Lockup Detection"
> + select SOFTLOCKUP_DETECTOR
> + select HARDLOCKUP_DETECTOR
> + select HARDLOCKUP_DETECTOR_CORE
> + depends on HPET_TIMER && HPET && X86_64
> + help
> +   Say y to enable a hardlockup detector that is driven by an High-

   by a

> +   Precision Event Timer. This option is helpful to not use counters
> +   from the Performance Monitoring Unit to drive the detector.
> +
>  config X86_DECODER_SELFTEST
>   bool "x86 instruction decoder selftest"
>   depends on DEBUG_KERNEL && KPROBES


-- 
~Randy


Re: [RFC PATCH v3 04/21] x86/hpet: Add hpet_set_comparator() for periodic and one-shot modes

2019-05-14 Thread Randy Dunlap
On 5/14/19 7:01 AM, Ricardo Neri wrote:
> Instead of setting the timer period directly in hpet_set_periodic(), add a
> new helper function hpet_set_comparator() that only sets the accumulator
> and comparator. hpet_set_periodic() will only prepare the timer for
> periodic mode and leave the expiration programming to
> hpet_set_comparator().
> 
> This new function can also be used by other components (e.g., the HPET-
> based hardlockup detector) which also need to configure HPET timers. Thus,
> add its declaration into the hpet header file.
> 
> Cc: "H. Peter Anvin" 
> Cc: Ashok Raj 
> Cc: Andi Kleen 
> Cc: Tony Luck 
> Cc: Philippe Ombredanne 
> Cc: Kate Stewart 
> Cc: "Rafael J. Wysocki" 
> Cc: Stephane Eranian 
> Cc: Suravee Suthikulpanit 
> Cc: "Ravi V. Shankar" 
> Cc: x...@kernel.org
> Originally-by: Suravee Suthikulpanit 
> Signed-off-by: Ricardo Neri 
> ---
>  arch/x86/include/asm/hpet.h |  1 +
>  arch/x86/kernel/hpet.c  | 57 -
>  2 files changed, 45 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/x86/include/asm/hpet.h b/arch/x86/include/asm/hpet.h
> index f132fbf984d4..e7098740f5ee 100644
> --- a/arch/x86/include/asm/hpet.h
> +++ b/arch/x86/include/asm/hpet.h
> @@ -102,6 +102,7 @@ extern int hpet_rtc_timer_init(void);
>  extern irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id);
>  extern int hpet_register_irq_handler(rtc_irq_handler handler);
>  extern void hpet_unregister_irq_handler(rtc_irq_handler handler);
> +extern void hpet_set_comparator(int num, unsigned int cmp, unsigned int 
> period);
>  
>  #endif /* CONFIG_HPET_EMULATE_RTC */
>  
> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> index 560fc28e1d13..c5c5fc150193 100644
> --- a/arch/x86/kernel/hpet.c
> +++ b/arch/x86/kernel/hpet.c
> @@ -289,6 +289,46 @@ static void hpet_legacy_clockevent_register(void)
>   printk(KERN_DEBUG "hpet clockevent registered\n");
>  }
>  
> +/**
> + * hpet_set_comparator() - Helper function for setting comparator register
> + * @num: The timer ID
> + * @cmp: The value to be written to the comparator/accumulator
> + * @period:  The value to be written to the period (0 = oneshot mode)
> + *
> + * Helper function for updating comparator, accumulator and period values.
> + *
> + * In periodic mode, HPET needs HPET_TN_SETVAL to be set before writing
> + * to the Tn_CMP to update the accumulator. Then, HPET needs a second
> + * write (with HPET_TN_SETVAL cleared) to Tn_CMP to set the period.
> + * The HPET_TN_SETVAL bit is automatically cleared after the first write.
> + *
> + * For one-shot mode, HPET_TN_SETVAL does not need to be set.
> + *
> + * See the following documents:
> + *   - Intel IA-PC HPET (High Precision Event Timers) Specification
> + *   - AMD-8111 HyperTransport I/O Hub Data Sheet, Publication # 24674
> + */
> +void hpet_set_comparator(int num, unsigned int cmp, unsigned int period)
> +{
> + if (period) {
> + unsigned int v = hpet_readl(HPET_Tn_CFG(num));
> +
> + hpet_writel(v | HPET_TN_SETVAL, HPET_Tn_CFG(num));
> + }
> +
> + hpet_writel(cmp, HPET_Tn_CMP(num));
> +
> + if (!period)
> + return;
> +
> + /* This delay is seldom used: never in one-shot mode and in periodic
> +  * only when reprogramming the timer.
> +  */

comment style warning ;)

> + udelay(1);
> + hpet_writel(period, HPET_Tn_CMP(num));
> +}
> +EXPORT_SYMBOL_GPL(hpet_set_comparator);
> +
>  static int hpet_set_periodic(struct clock_event_device *evt, int timer)
>  {
>   unsigned int cfg, cmp, now;
> @@ -300,19 +340,10 @@ static int hpet_set_periodic(struct clock_event_device 
> *evt, int timer)
>   now = hpet_readl(HPET_COUNTER);
>   cmp = now + (unsigned int)delta;
>   cfg = hpet_readl(HPET_Tn_CFG(timer));
> - cfg |= HPET_TN_ENABLE | HPET_TN_PERIODIC | HPET_TN_SETVAL |
> -HPET_TN_32BIT;
> - hpet_writel(cfg, HPET_Tn_CFG(timer));
> - hpet_writel(cmp, HPET_Tn_CMP(timer));
> - udelay(1);
> - /*
> -  * HPET on AMD 81xx needs a second write (with HPET_TN_SETVAL
> -  * cleared) to T0_CMP to set the period. The HPET_TN_SETVAL
> -  * bit is automatically cleared after the first write.
> -  * (See AMD-8111 HyperTransport I/O Hub Data Sheet,
> -  * Publication # 24674)
> -  */
> - hpet_writel((unsigned int)delta, HPET_Tn_CMP(timer));
> + cfg |= HPET_TN_ENABLE | HPET_TN_PERIODIC | HPET_TN_32BIT;
> +
> + hpet_set_comparator(timer, cmp, (unsigned int)delta);
> +
>   hpet_start_counter();
>   hpet_print_config();
>  
> 


-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC PATCH v3 03/21] x86/hpet: Calculate ticks-per-second in a separate function

2019-05-14 Thread Randy Dunlap
On 5/14/19 7:01 AM, Ricardo Neri wrote:
> It is easier to compute the expiration times of an HPET timer by using
> its frequency (i.e., the number of times it ticks in a second) than its
> period, as given in the capabilities register.
> 
> In addition to the HPET char driver, the HPET-based hardlockup detector
> will also need to know the timer's frequency. Thus, create a common
> function that both can use.
> 
> Cc: "H. Peter Anvin" 
> Cc: Ashok Raj 
> Cc: Andi Kleen 
> Cc: Tony Luck 
> Cc: Clemens Ladisch 
> Cc: Arnd Bergmann 
> Cc: Philippe Ombredanne 
> Cc: Kate Stewart 
> Cc: "Rafael J. Wysocki" 
> Cc: Stephane Eranian 
> Cc: Suravee Suthikulpanit 
> Cc: "Ravi V. Shankar" 
> Cc: x...@kernel.org
> Signed-off-by: Ricardo Neri 
> ---
>  drivers/char/hpet.c  | 31 ---
>  include/linux/hpet.h |  1 +
>  2 files changed, 25 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
> index d0ad85900b79..bdcbecfdb858 100644
> --- a/drivers/char/hpet.c
> +++ b/drivers/char/hpet.c
> @@ -836,6 +836,29 @@ static unsigned long hpet_calibrate(struct hpets *hpetp)
>   return ret;
>  }
>  
> +u64 hpet_get_ticks_per_sec(u64 hpet_caps)
> +{
> + u64 ticks_per_sec, period;
> +
> + period = (hpet_caps & HPET_COUNTER_CLK_PERIOD_MASK) >>
> +  HPET_COUNTER_CLK_PERIOD_SHIFT; /* fs, 10^-15 */
> +
> + /*
> +  * The frequency is the reciprocal of the period. The period is given
> +  * femtoseconds per second. Thus, prepare a dividend to obtain the

 * in femtoseconds per second.

> +  * frequency in ticks per second.
> +  */
> +
> + /* 10^15 femtoseconds per second */
> + ticks_per_sec = 1000uLL;

ULL is overwhelmingly used in the kernel.

> + ticks_per_sec += period >> 1; /* round */
> +
> + /* The quotient is put in the dividend. We drop the remainder. */
> + do_div(ticks_per_sec, period);
> +
> + return ticks_per_sec;
> +}
> +
>  int hpet_alloc(struct hpet_data *hdp)
>  {
>   u64 cap, mcfg;
> @@ -844,7 +867,6 @@ int hpet_alloc(struct hpet_data *hdp)
>   struct hpets *hpetp;
>   struct hpet __iomem *hpet;
>   static struct hpets *last;
> - unsigned long period;
>   unsigned long long temp;
>   u32 remainder;
>  
> @@ -894,12 +916,7 @@ int hpet_alloc(struct hpet_data *hdp)
>  
>   last = hpetp;
>  
> - period = (cap & HPET_COUNTER_CLK_PERIOD_MASK) >>
> - HPET_COUNTER_CLK_PERIOD_SHIFT; /* fs, 10^-15 */
> - temp = 1000uLL; /* 10^15 femtoseconds per second */
> - temp += period >> 1; /* round */
> - do_div(temp, period);
> - hpetp->hp_tick_freq = temp; /* ticks per second */
> + hpetp->hp_tick_freq = hpet_get_ticks_per_sec(cap);
>  
>   printk(KERN_INFO "hpet%d: at MMIO 0x%lx, IRQ%s",
>   hpetp->hp_which, hdp->hd_phys_address,
> diff --git a/include/linux/hpet.h b/include/linux/hpet.h
> index 8604564b985d..e7b36bcf4699 100644
> --- a/include/linux/hpet.h
> +++ b/include/linux/hpet.h
> @@ -107,5 +107,6 @@ static inline void hpet_reserve_timer(struct hpet_data 
> *hd, int timer)
>  }
>  
>  int hpet_alloc(struct hpet_data *);
> +u64 hpet_get_ticks_per_sec(u64 hpet_caps);
>  
>  #endif   /* !__HPET__ */
> 


-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/9] mm: Introduce new vm_insert_range API

2018-11-16 Thread Randy Dunlap
On 11/16/18 12:15 AM, Souptick Joarder wrote:
> On Fri, Nov 16, 2018 at 12:11 PM Matthew Wilcox  wrote:
>>
>> On Fri, Nov 16, 2018 at 11:00:30AM +0530, Souptick Joarder wrote:
>>> On Thu, Nov 15, 2018 at 11:44 PM Randy Dunlap  wrote:
>>>> On 11/15/18 7:45 AM, Souptick Joarder wrote:
>>>> What is the opposite of vm_insert_range() or even of vm_insert_page()?
>>>> or is there no need for that?
>>>
>>> There is no opposite function of vm_insert_range() / vm_insert_page().
>>> My understanding is, in case of any error, mmap handlers will return the
>>> err to user process and user space will decide the next action. So next
>>> time when mmap handler is getting invoked it will map from the beginning.
>>> Correct me if I am wrong.
>>
>> The opposite function, I suppose, is unmap_region().
>>
>>>> s/no./number/
>>>
>>> I didn't get it ??
>>
>> This is a 'sed' expression.  's' is the 'substitute' command; the /
>> is a separator, 'no.' is what you wrote, and 'number' is what Randy
>> is recommending instead.
> 
> Ok. Will change it in v2.

Thanks.

>>>>> + for (i = 0; i < page_count; i++) {
>>>>> + ret = vm_insert_page(vma, uaddr, pages[i]);
>>>>> + if (ret < 0)
>>>>> + return ret;
>>>>
>>>> For a non-trivial value of page_count:
>>>> Is it a problem if vm_insert_page() succeeds for several pages
>>>> and then fails?
>>>
>>> No, it will be considered as total failure and mmap handler will return
>>> the err to user space.
>>
>> I think what Randy means is "What happens to the inserted pages?" and
>> the answer is that mmap_region() jumps to the 'unmap_and_free_vma'
>> label, which is an accurate name.

which says:

/* Undo any partial mapping done by a device driver. */
unmap_region(mm, vma, prev, vma->vm_start, vma->vm_end);

and that is what I was missing.  Thanks.

> Sorry for incorrect understanding of the question.

No problem.


-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/9] mm: Introduce new vm_insert_range API

2018-11-15 Thread Randy Dunlap
On 11/15/18 7:45 AM, Souptick Joarder wrote:
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
> 
> As this pattern is common across different drivers, it can
> be generalized by creating a new function and use it across
> the drivers.
> 
> vm_insert_range is the new API which will be used to map a
> range of kernel memory/pages to user vma.
> 
> Signed-off-by: Souptick Joarder 
> Reviewed-by: Matthew Wilcox 
> ---
>  include/linux/mm_types.h |  3 +++
>  mm/memory.c  | 28 
>  mm/nommu.c   |  7 +++
>  3 files changed, 38 insertions(+)

Hi,

What is the opposite of vm_insert_range() or even of vm_insert_page()?
or is there no need for that?


> diff --git a/mm/memory.c b/mm/memory.c
> index 15c417e..da904ed 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1478,6 +1478,34 @@ static int insert_page(struct vm_area_struct *vma, 
> unsigned long addr,
>  }
>  
>  /**
> + * vm_insert_range - insert range of kernel pages into user vma
> + * @vma: user vma to map to
> + * @addr: target user address of this page
> + * @pages: pointer to array of source kernel pages
> + * @page_count: no. of pages need to insert into user vma

s/no./number/

> + *
> + * This allows drivers to insert range of kernel pages they've allocated
> + * into a user vma. This is a generic function which drivers can use
> + * rather than using their own way of mapping range of kernel pages into
> + * user vma.
> + */
> +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> + struct page **pages, unsigned long page_count)
> +{
> + unsigned long uaddr = addr;
> + int ret = 0, i;
> +
> + for (i = 0; i < page_count; i++) {
> + ret = vm_insert_page(vma, uaddr, pages[i]);
> + if (ret < 0)
> + return ret;

For a non-trivial value of page_count:
Is it a problem if vm_insert_page() succeeds for several pages
and then fails?

> + uaddr += PAGE_SIZE;
> + }
> +
> + return ret;
> +}
> +
> +/**
>   * vm_insert_page - insert single page into user vma
>   * @vma: user vma to map to
>   * @addr: target user address of this page


thanks.
-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dma-direct: document the zone selection logic

2018-10-01 Thread Randy Dunlap
On 10/1/18 1:10 PM, Christoph Hellwig wrote:
> What we are doing here isn't quite obvious, so add a comment explaining
> it.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  kernel/dma/direct.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index ba6f5956a291..14b966e2349a 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -84,7 +84,14 @@ static gfp_t __dma_direct_optimal_gfp_mask(struct device 
> *dev, u64 dma_mask,
>   else
>   *phys_mask = dma_to_phys(dev, dma_mask);
>  
> - /* GFP_DMA32 and GFP_DMA are no ops without the corresponding zones: */
> + /*
> +  * Optimistically try the zone that the physicall address mask falls

physical

> +  * into first.  If that returns memory that isn't actually addressable
> +  * we will fallback to the next lower zone and try again.
> +  *
> +  * Note that GFP_DMA32 and GFP_DMA are no ops without the corresponding
> +  * zones.
> +  */
>   if (*phys_mask <= DMA_BIT_MASK(ARCH_ZONE_DMA_BITS))
>   return GFP_DMA;
>   if (*phys_mask <= DMA_BIT_MASK(32))
> 

thanks for the documentation.

-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/7] vfio/sdmdev: Add documents for WarpDrive framework

2018-09-06 Thread Randy Dunlap
Hi,

On 09/02/2018 05:51 PM, Kenneth Lee wrote:
> From: Kenneth Lee 
> 
> WarpDrive is a common user space accelerator framework.  Its main component
> in Kernel is called sdmdev, Share Domain Mediated Device. It exposes
> the hardware capabilities to the user space via vfio-mdev. So processes in
> user land can obtain a "queue" by open the device and direct access the
> hardware MMIO space or do DMA operation via VFIO interface.
> 
> WarpDrive is intended to be used with Jean Philippe Brucker's SVA
> patchset to support multi-process. But This is not a must.  Without the
> SVA patches, WarpDrive can still work for one process for every hardware
> device.
> 
> This patch add detail documents for the framework.
> 
> Signed-off-by: Kenneth Lee 
> ---
>  Documentation/00-INDEX|   2 +
>  Documentation/warpdrive/warpdrive.rst | 100 
>  Documentation/warpdrive/wd-arch.svg   | 728 ++
>  3 files changed, 830 insertions(+)
>  create mode 100644 Documentation/warpdrive/warpdrive.rst
>  create mode 100644 Documentation/warpdrive/wd-arch.svg

> diff --git a/Documentation/warpdrive/warpdrive.rst 
> b/Documentation/warpdrive/warpdrive.rst
> new file mode 100644
> index ..6d2a5d1e08c4
> --- /dev/null
> +++ b/Documentation/warpdrive/warpdrive.rst
> @@ -0,0 +1,100 @@
> +Introduction of WarpDrive
> +=
> +
> +*WarpDrive* is a general accelerator framework for user space. It intends to
> +provide interface for the user process to send request to hardware
> +accelerator without heavy user-kernel interaction cost.
> +
> +The *WarpDrive* user library is supposed to provide a pipe-based API, such 
> as:

Do you say "is supposed to" because it doesn't do that (yet)?
Or you could just change that to say:

   The WarpDrive user library provides a pipe-based API, such as:


> +::
> +int wd_request_queue(struct wd_queue *q);
> +void wd_release_queue(struct wd_queue *q);
> +
> +int wd_send(struct wd_queue *q, void *req);
> +int wd_recv(struct wd_queue *q, void **req);
> +int wd_recv_sync(struct wd_queue *q, void **req);
> +int wd_flush(struct wd_queue *q);
> +
> +*wd_request_queue* creates the pipe connection, *queue*, between the
> +application and the hardware. The application sends request and pulls the
> +answer back by asynchronized wd_send/wd_recv, which directly interact with 
> the
> +hardware (by MMIO or share memory) without syscall.
> +
> +*WarpDrive* maintains a unified application address space among all involved
> +accelerators.  With the following APIs: ::

Seems like an extra '.' there.  How about:

  accelerators with the following APIs: ::

> +
> +int wd_mem_share(struct wd_queue *q, const void *addr,
> + size_t size, int flags);
> +void wd_mem_unshare(struct wd_queue *q, const void *addr, size_t 
> size);
> +
> +The referred process space shared by these APIs can be directly referred by 
> the
> +hardware. The process can also dedicate its whole process space with flags,
> +*WD_SHARE_ALL* (not in this patch yet).
> +
> +The name *WarpDrive* is simply a cool and general name meaning the framework
> +makes the application faster. As it will be explained in this text later, the
> +facility in kernel is called *SDMDEV*, namely "Share Domain Mediated Device".
> +
> +
> +How does it work
> +
> +
> +*WarpDrive* is built upon *VFIO-MDEV*. The queue is wrapped as *mdev* in 
> VFIO.
> +So memory sharing can be done via standard VFIO standard DMA interface.
> +
> +The architecture is illustrated as follow figure:
> +
> +.. image:: wd-arch.svg
> +:alt: WarpDrive Architecture
> +
> +Accelerator driver shares its capability via *SDMDEV* API: ::
> +
> +vfio_sdmdev_register(struct vfio_sdmdev *sdmdev);
> +vfio_sdmdev_unregister(struct vfio_sdmdev *sdmdev);
> +vfio_sdmdev_wake_up(struct spimdev_queue *q);
> +
> +*vfio_sdmdev_register* is a helper function to register the hardware to the
> +*VFIO_MDEV* framework. The queue creation is done by *mdev* creation 
> interface.
> +
> +*WarpDrive* User library mmap the mdev to access its mmio space and shared

s/mmio/MMIO/

> +memory. Request can be sent to, or receive from, hardware in this mmap-ed
> +space until the queue is full or empty.
> +
> +The user library can wait on the queue by ioctl(VFIO_SDMDEV_CMD_WAIT) the 
> mdev
> +if the queue is full or empty. If the queue status is changed, the hardware
> +driver use *vfio_sdmdev_wake_up* to wake up the waiting process.
> +
> +
> +Multiple processes support
> +==
> +
> +In the latest mainline kernel (4.18) when this document is written,
> +multi-process is not supported in VFIO yet.
> +
> +Jean Philippe Brucker has a patchset to enable it[1]_. We have tested it
> +with our hardware (which is known as *D06*). It works well. *WarpDrive* rely
> +on them to support multiple processes. If it is not 

Re: [PATCH 7/7] vfio/sdmdev: add user sample

2018-09-02 Thread Randy Dunlap
On 09/02/2018 05:52 PM, Kenneth Lee wrote:
> From: Kenneth Lee 
> 
> This is the sample code to demostrate how WrapDrive user application
> should be.
> 
> It contains:
> 
> 1. wd.[ch], the common library to provide WrapDrive interface.

WarpDrive

> 2. drv/*, the user driver to access the hardware upon spimdev
> 3. test/*, the test application to use WrapDrive interface to access the

 WarpDrive

>hardware queue(s) of the accelerator.
> 
> The Hisilicon HIP08 ZIP accelerator is used in this sample.
> 
> Signed-off-by: Zaibo Xu 
> Signed-off-by: Kenneth Lee 
> Signed-off-by: Hao Fang 
> Signed-off-by: Zhou Wang 
> ---
>  samples/warpdrive/AUTHORS  |   2 +
>  samples/warpdrive/ChangeLog|   1 +
>  samples/warpdrive/Makefile.am  |   9 +
>  samples/warpdrive/NEWS |   1 +
>  samples/warpdrive/README   |  32 +++
>  samples/warpdrive/autogen.sh   |   3 +
>  samples/warpdrive/cleanup.sh   |  13 ++
>  samples/warpdrive/configure.ac |  52 +
>  samples/warpdrive/drv/hisi_qm_udrv.c   | 223 ++
>  samples/warpdrive/drv/hisi_qm_udrv.h   |  53 +
>  samples/warpdrive/test/Makefile.am |   7 +
>  samples/warpdrive/test/comp_hw.h   |  23 ++
>  samples/warpdrive/test/test_hisi_zip.c | 206 +
>  samples/warpdrive/wd.c | 309 +
>  samples/warpdrive/wd.h | 154 
>  samples/warpdrive/wd_adapter.c |  74 ++
>  samples/warpdrive/wd_adapter.h |  43 
>  17 files changed, 1205 insertions(+)
>  create mode 100644 samples/warpdrive/AUTHORS
>  create mode 100644 samples/warpdrive/ChangeLog
>  create mode 100644 samples/warpdrive/Makefile.am
>  create mode 100644 samples/warpdrive/NEWS
>  create mode 100644 samples/warpdrive/README
>  create mode 100755 samples/warpdrive/autogen.sh
>  create mode 100755 samples/warpdrive/cleanup.sh
>  create mode 100644 samples/warpdrive/configure.ac
>  create mode 100644 samples/warpdrive/drv/hisi_qm_udrv.c
>  create mode 100644 samples/warpdrive/drv/hisi_qm_udrv.h
>  create mode 100644 samples/warpdrive/test/Makefile.am
>  create mode 100644 samples/warpdrive/test/comp_hw.h
>  create mode 100644 samples/warpdrive/test/test_hisi_zip.c
>  create mode 100644 samples/warpdrive/wd.c
>  create mode 100644 samples/warpdrive/wd.h
>  create mode 100644 samples/warpdrive/wd_adapter.c
>  create mode 100644 samples/warpdrive/wd_adapter.h

> diff --git a/samples/warpdrive/README b/samples/warpdrive/README
> new file mode 100644
> index ..3adf66b112fc
> --- /dev/null
> +++ b/samples/warpdrive/README
> @@ -0,0 +1,32 @@
> +WD User Land Demonstration
> +==
> +
> +This directory contains some applications and libraries to demonstrate how a
> +
> +WrapDrive application can be constructed.

   WarpDrive

> +
> +
> +As a demo, we try to make it simple and clear for understanding. It is not
> +
> +supposed to be used in business scenario.
> +
> +
> +The directory contains the following elements:
> +
> +wd.[ch]
> + A demonstration WrapDrive fundamental library which wraps the basic

WarpDrive

> + operations to the WrapDrive-ed device.

  WarpDrive

> +
> +wd_adapter.[ch]
> + User driver adaptor for wd.[ch]
> +
> +wd_utils.[ch]
> + Some utitlities function used by WD and its drivers
> +
> +drv/*
> + User drivers. It helps to fulfill the semantic of wd.[ch] for
> + particular hardware
> +
> +test/*
> + Test applications to use the wrapdrive library

 warpdrive

-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 6/7] crypto: add sdmdev support to Hisilicon QM

2018-09-02 Thread Randy Dunlap
On 09/02/2018 05:52 PM, Kenneth Lee wrote:
> diff --git a/drivers/crypto/hisilicon/Kconfig 
> b/drivers/crypto/hisilicon/Kconfig
> index 1d155708cd69..b85fab48fdab 100644
> --- a/drivers/crypto/hisilicon/Kconfig
> +++ b/drivers/crypto/hisilicon/Kconfig
> @@ -17,6 +17,16 @@ config CRYPTO_DEV_HISI_SEC
> To compile this as a module, choose M here: the module
> will be called hisi_sec.
>  
> +config CRYPTO_DEV_HISI_SDMDEV
> + bool "Enable SDMDEV interface"
> + depends on CRYPTO_DEV_HISILICON
> + select VFIO_SDMDEV
> + help
> +   Enable this enable the SDMDEV, "shared IOMMU Domain Mediated Device"

At a minimum:
  Enable this to enable the SDMDEV,

although that could be done better.  Maybe just:
  Enable the SDMDEV "shared IOMMU Domain Mediated Device"

  
> +   interface for all Hisilicon accelerators if they can. The SDMDEV

probably drop "if they can":  accelerators.  The SDMDEV interface

> +   enable the WarpDrive user space accelerator driver to access the

  enables

> +   hardware function directly.
> +


-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 4/7] crypto: add hisilicon Queue Manager driver

2018-09-02 Thread Randy Dunlap
On 09/02/2018 05:52 PM, Kenneth Lee wrote:
> diff --git a/drivers/crypto/hisilicon/Kconfig 
> b/drivers/crypto/hisilicon/Kconfig
> index 8ca9c503bcb0..02a6eef84101 100644
> --- a/drivers/crypto/hisilicon/Kconfig
> +++ b/drivers/crypto/hisilicon/Kconfig
> @@ -1,4 +1,8 @@
>  # SPDX-License-Identifier: GPL-2.0
> +config CRYPTO_DEV_HISILICON
> + tristate "Support for HISILICON CRYPTO ACCELERATOR"
> + help
> +   Enable this to use Hisilicon Hardware Accelerators

Accelerators.


-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 3/7] vfio: add sdmdev support

2018-09-02 Thread Randy Dunlap
On 09/02/2018 05:52 PM, Kenneth Lee wrote:
> diff --git a/drivers/vfio/sdmdev/Kconfig b/drivers/vfio/sdmdev/Kconfig
> new file mode 100644
> index ..51474272870d
> --- /dev/null
> +++ b/drivers/vfio/sdmdev/Kconfig
> @@ -0,0 +1,10 @@
> +# SPDX-License-Identifier: GPL-2.0
> +config VFIO_SDMDEV
> + tristate "Support for Share Domain MDEV"
> + depends on VFIO_MDEV_DEVICE
> + help
> +   Support for VFIO Share Domain MDEV, which enables the kernel to
> +   support light weight hardware accelerator framework, WarpDrive.

  lightweight

> +
> +   To compile this as a module, choose M here: the module will be called
> +   sdmdev.


thanks,
-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC PATCH 11/11] powerpc/svm: Increase SWIOTLB buffer size

2018-08-24 Thread Randy Dunlap
On 08/24/2018 09:25 AM, Thiago Jung Bauermann wrote:
> From: Anshuman Khandual 
> 
> SWIOTLB buffer default size (64MB) is not enough for large sequential write
> operations which eventually leads to kernel crash like here.
> 
> virtio-pci :00:05.0: swiotlb buffer is full (sz: 327680 bytes)
> virtio-pci :00:05.0: DMA: Out of SW-IOMMU space for 327680 bytes
> Kernel panic - not syncing: DMA: Random memory could be DMA read
> CPU: 12 PID: 3985 Comm: mkfs.ext4 Not tainted 4.18.0-rc4+ #285
> Call Trace:
> [c007d2a27020] [c0cfdffc] dump_stack+0xb0/0xf4 (unreliable)
> [c007d2a27060] [c0112a98] panic+0x140/0x328
> [c007d2a270f0] [c01b4f88] swiotlb_full+0x108/0x130
> [c007d2a27180] [c01b5f6c] swiotlb_map_page+0x25c/0x2c0
> [c007d2a271e0] [c07bfaf8] vring_map_one_sg.isra.0+0x58/0x70
> [c007d2a27200] [c07c08dc] virtqueue_add_sgs+0x1bc/0x690
> [c007d2a272f0] [d42a1280] virtio_queue_rq+0x358/0x4a0 [virtio_blk]
> [c007d2a273d0] [c06b5d68] blk_mq_dispatch_rq_list+0x1f8/0x6d0
> ..
> 
> Increase the SWIOTLB size to 1GB on Ultravisor based secure guests.
> 
> Signed-off-by: Anshuman Khandual 
> Signed-off-by: Thiago Jung Bauermann 
> ---
>  arch/powerpc/Kconfig | 5 +
>  kernel/dma/swiotlb.c | 5 +
>  2 files changed, 10 insertions(+)
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 1466d1234723..fee7194ce9e4 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -457,6 +457,11 @@ config PPC_SVM
>  
>If unsure, say "N".
>  
> +config SWIOTLB_DEFAULT_SIZE
> +   int "Size of Software I/O TLB buffer (in MiB)"
> +   default "1024"

I would add a "range" to limit (restrict) how small or large that can be.  E.g.:

range 16 102400

or even smaller for the maximum value...

> +   depends on PPC_SVM
> +
>  config PPC_TRANSACTIONAL_MEM
> bool "Transactional Memory support for POWERPC"
> depends on PPC_BOOK3S_64
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index 04b68d9dffac..32dc67422d8a 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -146,8 +146,13 @@ void swiotlb_set_max_segment(unsigned int val)
>   max_segment = rounddown(val, PAGE_SIZE);
>  }
>  
> +#ifdef CONFIG_SWIOTLB_DEFAULT_SIZE
> +#define IO_TLB_DEFAULT_SIZE ((unsigned long) CONFIG_SWIOTLB_DEFAULT_SIZE << 
> 20)
> +#else
>  /* default to 64MB */
>  #define IO_TLB_DEFAULT_SIZE (64UL<<20)
> +#endif
> +
>  unsigned long swiotlb_size_or_default(void)
>  {
>   unsigned long size;
> 


-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC PATCH 3/7] vfio: add spimdev support

2018-08-01 Thread Randy Dunlap
On 08/01/2018 03:22 AM, Kenneth Lee wrote:
> From: Kenneth Lee 
> 
> SPIMDEV is "Share Parent IOMMU Mdev". It is a vfio-mdev. But differ from
> the general vfio-mdev:
> 
> 1. It shares its parent's IOMMU.
> 2. There is no hardware resource attached to the mdev is created. The
> hardware resource (A `queue') is allocated only when the mdev is
> opened.
> 
> Currently only the vfio type-1 driver is updated to make it to be aware
> of.
> 
> Signed-off-by: Kenneth Lee 
> Signed-off-by: Zaibo Xu 
> Signed-off-by: Zhou Wang 
> ---
>  drivers/vfio/Kconfig|   1 +
>  drivers/vfio/Makefile   |   1 +
>  drivers/vfio/spimdev/Kconfig|  10 +
>  drivers/vfio/spimdev/Makefile   |   3 +
>  drivers/vfio/spimdev/vfio_spimdev.c | 421 
>  drivers/vfio/vfio_iommu_type1.c | 136 -
>  include/linux/vfio_spimdev.h|  95 +++
>  include/uapi/linux/vfio_spimdev.h   |  28 ++
>  8 files changed, 689 insertions(+), 6 deletions(-)
>  create mode 100644 drivers/vfio/spimdev/Kconfig
>  create mode 100644 drivers/vfio/spimdev/Makefile
>  create mode 100644 drivers/vfio/spimdev/vfio_spimdev.c
>  create mode 100644 include/linux/vfio_spimdev.h
>  create mode 100644 include/uapi/linux/vfio_spimdev.h
> 
> diff --git a/drivers/vfio/spimdev/Kconfig b/drivers/vfio/spimdev/Kconfig
> new file mode 100644
> index ..1226301f9d0e
> --- /dev/null
> +++ b/drivers/vfio/spimdev/Kconfig
> @@ -0,0 +1,10 @@
> +# SPDX-License-Identifier: GPL-2.0
> +config VFIO_SPIMDEV
> + tristate "Support for Share Parent IOMMU MDEV"
> + depends on VFIO_MDEV_DEVICE
> + help
> +   Support for VFIO Share Parent IOMMU MDEV, which enable the kernel to

  enables

> +   support for the light weight hardware accelerator framework, 
> WrapDrive.

  support the lightweight hardware accelerator framework, WrapDrive.

> +
> +   To compile this as a module, choose M here: the module will be called
> +   spimdev.


-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v9 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

2018-06-14 Thread Randy Dunlap
On 06/12/2018 02:41 PM, Gary R Hook wrote:
> Implement a skeleton framework for debugfs support in the AMD
> IOMMU.  Add an AMD-specific Kconfig boolean that depends upon
> general enablement of DebugFS in the IOMMU.
> 
> Signed-off-by: Gary R Hook 

Gary,

Looks good to me.  Thanks.

> ---
>  drivers/iommu/Kconfig |   12 
>  drivers/iommu/Makefile|1 +
>  drivers/iommu/amd_iommu_debugfs.c |   33 +
>  drivers/iommu/amd_iommu_init.c|6 --
>  drivers/iommu/amd_iommu_proto.h   |6 ++
>  drivers/iommu/amd_iommu_types.h   |5 +
>  6 files changed, 61 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/iommu/amd_iommu_debugfs.c
> 
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index f9af25ac409f..5a9cef113763 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -146,6 +146,18 @@ config AMD_IOMMU_V2
> hardware. Select this option if you want to use devices that support
> the PCI PRI and PASID interface.
>  
> +config AMD_IOMMU_DEBUGFS
> + bool "Enable AMD IOMMU internals in DebugFS"
> + depends on AMD_IOMMU && IOMMU_DEBUGFS
> + ---help---
> +   !!!WARNING!!!  !!!WARNING!!!  !!!WARNING!!!  !!!WARNING!!!
> +
> +   DO NOT ENABLE THIS OPTION UNLESS YOU REALLY, -REALLY- KNOW WHAT YOU 
> ARE DOING!!!
> +   Exposes AMD IOMMU device internals in DebugFS.
> +
> +   This option is -NOT- intended for production environments, and should
> +   not generally be enabled.
> +
>  # Intel IOMMU support
>  config DMAR_TABLE
>   bool
> diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
> index 74cfbc392862..47fd6ea9de2d 100644
> --- a/drivers/iommu/Makefile
> +++ b/drivers/iommu/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_IOMMU_IOVA) += iova.o
>  obj-$(CONFIG_OF_IOMMU)   += of_iommu.o
>  obj-$(CONFIG_MSM_IOMMU) += msm_iommu.o
>  obj-$(CONFIG_AMD_IOMMU) += amd_iommu.o amd_iommu_init.o
> +obj-$(CONFIG_AMD_IOMMU_DEBUGFS) += amd_iommu_debugfs.o
>  obj-$(CONFIG_AMD_IOMMU_V2) += amd_iommu_v2.o
>  obj-$(CONFIG_ARM_SMMU) += arm-smmu.o
>  obj-$(CONFIG_ARM_SMMU_V3) += arm-smmu-v3.o


-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC PATCH 22/23] watchdog/hardlockup/hpet: Only enable the HPET watchdog via a boot parameter

2018-06-13 Thread Randy Dunlap
On 06/13/2018 05:58 PM, Ricardo Neri wrote:
> On Tue, Jun 12, 2018 at 10:26:57PM -0700, Randy Dunlap wrote:
>> On 06/12/2018 05:57 PM, Ricardo Neri wrote:
>>> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
>>> b/Documentation/admin-guide/kernel-parameters.txt
>>> index f2040d4..a8833c7 100644
>>> --- a/Documentation/admin-guide/kernel-parameters.txt
>>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>>> @@ -2577,7 +2577,7 @@
>>> Format: [state][,regs][,debounce][,die]
>>>  
>>> nmi_watchdog=   [KNL,BUGS=X86] Debugging features for SMP kernels
>>> -   Format: [panic,][nopanic,][num]
>>> +   Format: [panic,][nopanic,][num,][hpet]
>>> Valid num: 0 or 1
>>> 0 - turn hardlockup detector in nmi_watchdog off
>>> 1 - turn hardlockup detector in nmi_watchdog on
>>
>> This says that I can use "nmi_watchdog=hpet" without using 0 or 1.
>> Is that correct?
> 
> Yes, this what I meant. In my view, if you set nmi_watchdog=hpet it
> implies that you want to activate the NMI watchdog. In this case, perf.
> 
> I can see how this will be ambiguous for the case of perf and arch NMI
> watchdogs.
> 
> Alternative, a new parameter could be added; such as nmi_watchdog_type. I
> didn't want to add it in this patchset as I think that a single parameter
> can handle the enablement and type of the NMI watchdog.
> 
> What do you think?

I think it's OK like it is.

thanks,
-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC PATCH 22/23] watchdog/hardlockup/hpet: Only enable the HPET watchdog via a boot parameter

2018-06-12 Thread Randy Dunlap
On 06/12/2018 05:57 PM, Ricardo Neri wrote:
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index f2040d4..a8833c7 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2577,7 +2577,7 @@
>   Format: [state][,regs][,debounce][,die]
>  
>   nmi_watchdog=   [KNL,BUGS=X86] Debugging features for SMP kernels
> - Format: [panic,][nopanic,][num]
> + Format: [panic,][nopanic,][num,][hpet]
>   Valid num: 0 or 1
>   0 - turn hardlockup detector in nmi_watchdog off
>   1 - turn hardlockup detector in nmi_watchdog on

This says that I can use "nmi_watchdog=hpet" without using 0 or 1.
Is that correct?

> @@ -2587,6 +2587,9 @@
>   please see 'nowatchdog'.
>   This is useful when you use a panic=... timeout and
>   need the box quickly up again.
> + When hpet is specified, the NMI watchdog will be driven
> + by an HPET timer, if available in the system. Otherwise,
> + the perf-based implementation will be used.
>  
>   These settings can be accessed at runtime via
>   the nmi_watchdog and hardlockup_panic sysctls.


thanks,
-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC PATCH 16/23] watchdog/hardlockup: Add an HPET-based hardlockup detector

2018-06-12 Thread Randy Dunlap
Hi,

On 06/12/2018 05:57 PM, Ricardo Neri wrote:
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index c40c7b7..6e79833 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -828,6 +828,16 @@ config HARDLOCKUP_DETECTOR_PERF
>   bool
>   select SOFTLOCKUP_DETECTOR
>  
> +config HARDLOCKUP_DETECTOR_HPET
> + bool "Use HPET Timer for Hard Lockup Detection"
> + select SOFTLOCKUP_DETECTOR
> + select HARDLOCKUP_DETECTOR
> + depends on HPET_TIMER && HPET
> + help
> +   Say y to enable a hardlockup detector that is driven by an 
> High-Precision
> +   Event Timer. In addition to selecting this option, the command-line
> +   parameter nmi_watchdog option. See 
> Documentation/admin-guide/kernel-parameters.rst

The "In addition ..." thing is a broken (incomplete) sentence.

> +
>  #
>  # Enables a timestamp based low pass filter to compensate for perf based
>  # hard lockup detection which runs too fast due to turbo modes.


-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v8 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

2018-06-04 Thread Randy Dunlap
On 05/29/2018 11:39 AM, Greg KH wrote:
> On Tue, May 29, 2018 at 01:23:23PM -0500, Gary R Hook wrote:
>> Implement a skeleton framework for debugfs support in the
>> AMD IOMMU. Add a hidden boolean to Kconfig that is defined
>> for the AMD IOMMU when general IOMMY DebugFS support is
>> enabled.
>>
>> Signed-off-by: Gary R Hook 
>> ---
>>  drivers/iommu/Kconfig |4 
>>  drivers/iommu/Makefile|1 +
>>  drivers/iommu/amd_iommu_debugfs.c |   39 
>> +
>>  drivers/iommu/amd_iommu_init.c|6 --
>>  drivers/iommu/amd_iommu_proto.h   |6 ++
>>  drivers/iommu/amd_iommu_types.h   |5 +
>>  6 files changed, 59 insertions(+), 2 deletions(-)
>>  create mode 100644 drivers/iommu/amd_iommu_debugfs.c
>>
>> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
>> index f9af25ac409f..ec223f6f4ad4 100644
>> --- a/drivers/iommu/Kconfig
>> +++ b/drivers/iommu/Kconfig
>> @@ -137,6 +137,10 @@ config AMD_IOMMU
>>your BIOS for an option to enable it or if you have an IVRS ACPI
>>table.
>>  
>> +config AMD_IOMMU_DEBUGFS
>> +def_bool y
> 
> Why default y?  Can you not boot a box without this?  If not, it should
> not be Y.
> 
>> +depends on AMD_IOMMU && IOMMU_DEBUGFS
>> +
>>  config AMD_IOMMU_V2
>>  tristate "AMD IOMMU Version 2 driver"
>>  depends on AMD_IOMMU

Gary,

By far, most driver-debugfs additions are optional and include a user Kconfig 
prompt
so that user's can choose whether to enable it or not.

I suggest that the way forward is to fix Greg's debugfs_() api comments
and to add a prompt string to AMD_IOMMU_DEBUGFS.


-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v7 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

2018-05-18 Thread Randy Dunlap
On 05/18/2018 08:20 AM, Gary R Hook wrote:
> On 05/15/2018 08:46 AM, Joerg Roedel wrote:
>> On Mon, May 14, 2018 at 03:00:50PM -0500, Gary R Hook wrote:
>>> This was brought up a few weeks ago in, I believe, version 3 of this patch.
>>> That question was discussed (because that's what I did the first time out),
>>> and _someone_ _else_ asked about why I didn't just do it the way I've done
>>> it here.
>>
>> You don't have this problem if you put the code in amd_iommu.c in an
>> IOMMU_DEBUGFS ifdef.
> 
> Of course. My preference, however, is a separate file to avoid size creep. 
> That's why I've done it this way.
> 
> To whit: there have been threads discussing the advisability/acceptability of 
> using #ifdefs for debug code. My take-away was to avoid them. Perhaps I 
> misunderstood.
> 
> So: I don't understand your comment. Is this an observation, or is it an 
> imperative statement? I'd like for a maintainer to clearly indicate what is 
> acceptable, and I'll do it.
> 
> 

Hi,
I looked back at Robin Murphy's comments on April 17:


Well, you could do a makefile-level dependency i.e.:

ifeq ($(CONFIG_IOMMU_DEBUG), y)
obj-$(CONFIG_AMD_IOMMU) += amd_iommu_debugfs.o
obj-$(CONFIG_BLAH_IOMMU) += blah_iommu_debugfs.o
...
endif

Or alternatively have an intermediate silent Kconfig option:

config AMD_IOMMU_DEBUG
def_bool y
depends on AMD_IOMMU && IOMMU_DEBUG

The makefile option is arguably ugly, but does at least scale better ;)



I think the Kconfig option would have been the correct choice.

-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v7 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

2018-05-14 Thread Randy Dunlap
On 05/14/2018 01:00 PM, Gary R Hook wrote:
> On 05/14/2018 12:50 PM, Randy Dunlap wrote:
>> On 05/14/2018 10:20 AM, Gary R Hook wrote:
>>> Implement a skeleton framework for debugfs support in the
>>> AMD IOMMU.
>>>
>>> Signed-off-by: Gary R Hook <gary.h...@amd.com>
>>> ---
>>>   drivers/iommu/Makefile    |    5 +
>>>   drivers/iommu/amd_iommu_debugfs.c |   39 
>>> +
>>>   drivers/iommu/amd_iommu_init.c    |    6 --
>>>   drivers/iommu/amd_iommu_proto.h   |    6 ++
>>>   drivers/iommu/amd_iommu_types.h   |    3 +++
>>>   5 files changed, 57 insertions(+), 2 deletions(-)
>>>   create mode 100644 drivers/iommu/amd_iommu_debugfs.c
>>>
>>> diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
>>> index 74cfbc392862..dd980f7dd8b6 100644
>>> --- a/drivers/iommu/Makefile
>>> +++ b/drivers/iommu/Makefile
>>> @@ -30,3 +30,8 @@ obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
>>>   obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o
>>>   obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
>>>   obj-$(CONFIG_QCOM_IOMMU) += qcom_iommu.o
>>> +
>>> +# This ensures that only the required files are compiled
>>> +ifeq ($(CONFIG_IOMMU_DEBUGFS), y)
>>
>> Most Makefiles don't use a space before the 'y', but since you tested it,
>> I guess either way works.
> 
> Pretty sure whitespace isn't used as a delimiter in this construct. I could 
> be mistaken. But yes, it's perfectly serviceable.
> 
>> But why do this in the Makefile at all?  Why not just add another Kconfig
>> symbol and simplify the Makefile?
>>
>>> +obj-$(CONFIG_AMD_IOMMU) += amd_iommu_debugfs.o
>>> +endif
> 
> 
> This was brought up a few weeks ago in, I believe, version 3 of this patch. 
> That question was discussed (because that's what I did the first time out), 
> and _someone_ _else_ asked about why I didn't just do it the way I've done it 
> here.

Sorry I missed it.  I would have been glad to chime in at that time.

> Everyone has a preference.
> 
> I chose to simplify the choices and avoid multiple symbols, instead opting 
> for two switches: choose your device, and decide on Debug FS enablement for 
> it. IMO Very simple.
> 
> I can't fathom a scenario where this wouldn't work. Is there one?

Probably not.

But we used to have ugly, messy, convoluted makefiles with very little config 
help.
Then we got better kconfig tools (well, arguably :) and then the makefiles were
cleaned up and simplified a lot (or A LOT!).  We shouldn't want to go back 
there.

-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v7 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

2018-05-14 Thread Randy Dunlap
On 05/14/2018 10:20 AM, Gary R Hook wrote:
> Implement a skeleton framework for debugfs support in the
> AMD IOMMU.
> 
> Signed-off-by: Gary R Hook 
> ---
>  drivers/iommu/Makefile|5 +
>  drivers/iommu/amd_iommu_debugfs.c |   39 
> +
>  drivers/iommu/amd_iommu_init.c|6 --
>  drivers/iommu/amd_iommu_proto.h   |6 ++
>  drivers/iommu/amd_iommu_types.h   |3 +++
>  5 files changed, 57 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/iommu/amd_iommu_debugfs.c
> 
> diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
> index 74cfbc392862..dd980f7dd8b6 100644
> --- a/drivers/iommu/Makefile
> +++ b/drivers/iommu/Makefile
> @@ -30,3 +30,8 @@ obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
>  obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o
>  obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
>  obj-$(CONFIG_QCOM_IOMMU) += qcom_iommu.o
> +
> +# This ensures that only the required files are compiled
> +ifeq ($(CONFIG_IOMMU_DEBUGFS), y)

Most Makefiles don't use a space before the 'y', but since you tested it,
I guess either way works.

But why do this in the Makefile at all?  Why not just add another Kconfig
symbol and simplify the Makefile?

> +obj-$(CONFIG_AMD_IOMMU) += amd_iommu_debugfs.o
> +endif

-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] headers: untangle kmemleak.h from mm.h

2018-02-13 Thread Randy Dunlap
On 02/11/2018 11:27 PM, Ingo Molnar wrote:
> 
> * Randy Dunlap <rdun...@infradead.org> wrote:
> 
>> From: Randy Dunlap <rdun...@infradead.org>
>>
>> Currently  #includes  for no obvious
>> reason. It looks like it's only a convenience, so remove kmemleak.h
>> from slab.h and add  to any users of kmemleak_*
>> that don't already #include it.
>> Also remove  from source files that do not use it.
>>
>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>> would be good to run it through the 0day bot for other $ARCHes.
>> I have neither the horsepower nor the storage space for the other
>> $ARCHes.
>>
>> [slab.h is the second most used header file after module.h; kernel.h
>> is right there with slab.h. There could be some minor error in the
>> counting due to some #includes having comments after them and I
>> didn't combine all of those.]
>>
>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>> header files).
>>
>> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
> 
> Nice find:
> 
> Reviewed-by: Ingo Molnar <mi...@kernel.org>
> 
> I agree that it needs to go through 0-day to find any hidden dependencies we 
> might 
> have grown due to this.

Andrew,

This patch has mostly survived both 0day and ozlabs multi-arch testing with
2 build errors being reported by both of them.  I have posted patches for
those separately. (and are attached here)

other-patch-1:
lkml.kernel.org/r/5664ced1-a0cd-7e4e-71b6-9c3a97d68...@infradead.org
"lib/test_firmware: add header file to prevent build errors"

other-patch-2:
lkml.kernel.org/r/b3b7eebb-0e9f-f175-94a8-379c5ddca...@infradead.org
"integrity/security: fix digsig.c build error"

Will you see that these are merged or do you want me to repost them?

thanks,
-- 
~Randy
From: Randy Dunlap <rdun...@infradead.org>

security/integrity/digsig.c has build errors on some $ARCH due to a
missing header file, so add it.

  security/integrity/digsig.c:146:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]

Reported-by: Michael Ellerman <m...@ellerman.id.au>
Signed-off-by: Randy Dunlap <rdun...@infradead.org>
Cc: Mimi Zohar <zo...@linux.vnet.ibm.com>
Cc: linux-integr...@vger.kernel.org
Link: http://kisskb.ellerman.id.au/kisskb/head/13396/
---
 security/integrity/digsig.c |    1 +
 1 file changed, 1 insertion(+)

--- lnx-416-rc1.orig/security/integrity/digsig.c
+++ lnx-416-rc1/security/integrity/digsig.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 



From: Randy Dunlap <rdun...@infradead.org>

lib/test_firmware.c has build errors on some $ARCH due to a
missing header file, so add it.

  lib/test_firmware.c:134:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
  lib/test_firmware.c:620:25: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration]

Reported-by: Michael Ellerman <m...@ellerman.id.au>
Signed-off-by: Randy Dunlap <rdun...@infradead.org>
Cc: Wei Yongjun <weiyongj...@huawei.com>
Cc: Luis R. Rodriguez <mcg...@kernel.org>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Link: http://kisskb.ellerman.id.au/kisskb/head/13396/
---
 lib/test_firmware.c |1 +
 1 file changed, 1 insertion(+)

--- lnx-416-rc1.orig/lib/test_firmware.c
+++ lnx-416-rc1/lib/test_firmware.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TEST_FIRMWARE_NAME	"test-firmware.bin"
 #define TEST_FIRMWARE_NUM_REQS	4



___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] headers: untangle kmemleak.h from mm.h

2018-02-13 Thread Randy Dunlap
On 02/13/2018 02:09 AM, Michael Ellerman wrote:
> Randy Dunlap <rdun...@infradead.org> writes:
> 
>> On 02/12/2018 04:28 AM, Michael Ellerman wrote:
>>> Randy Dunlap <rdun...@infradead.org> writes:
>>>
>>>> From: Randy Dunlap <rdun...@infradead.org>
>>>>
>>>> Currently  #includes  for no obvious
>>>> reason. It looks like it's only a convenience, so remove kmemleak.h
>>>> from slab.h and add  to any users of kmemleak_*
>>>> that don't already #include it.
>>>> Also remove  from source files that do not use it.
>>>>
>>>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>>>> would be good to run it through the 0day bot for other $ARCHes.
>>>> I have neither the horsepower nor the storage space for the other
>>>> $ARCHes.
>>>>
>>>> [slab.h is the second most used header file after module.h; kernel.h
>>>> is right there with slab.h. There could be some minor error in the
>>>> counting due to some #includes having comments after them and I
>>>> didn't combine all of those.]
>>>>
>>>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>>>> header files).
>>>>
>>>> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
>>>
>>> I threw it at a random selection of configs and so far the only failures
>>> I'm seeing are:
>>>
>>>   lib/test_firmware.c:134:2: error: implicit declaration of function 
>>> 'vfree' [-Werror=implicit-function-declaration] 
>>> 
>>>  
>>>   lib/test_firmware.c:620:25: error: implicit declaration of function 
>>> 'vzalloc' [-Werror=implicit-function-declaration]
>>>   lib/test_firmware.c:620:2: error: implicit declaration of function 
>>> 'vzalloc' [-Werror=implicit-function-declaration]
>>>   security/integrity/digsig.c:146:2: error: implicit declaration of 
>>> function 'vfree' [-Werror=implicit-function-declaration]
>>
>> Both of those source files need to #include .
> 
> Yep, I added those and rebuilt. I don't see any more failures that look
> related to your patch.

Great, thanks.

I also sent patches for both of those.

>   http://kisskb.ellerman.id.au/kisskb/head/13399/
> 
> 
> I haven't gone through the defconfigs I have enabled for a while, so
> it's possible I have some missing but it's still a reasonable cross
> section.


-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] headers: untangle kmemleak.h from mm.h

2018-02-12 Thread Randy Dunlap
On 02/12/2018 04:28 AM, Michael Ellerman wrote:
> Randy Dunlap <rdun...@infradead.org> writes:
> 
>> From: Randy Dunlap <rdun...@infradead.org>
>>
>> Currently  #includes  for no obvious
>> reason. It looks like it's only a convenience, so remove kmemleak.h
>> from slab.h and add  to any users of kmemleak_*
>> that don't already #include it.
>> Also remove  from source files that do not use it.
>>
>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>> would be good to run it through the 0day bot for other $ARCHes.
>> I have neither the horsepower nor the storage space for the other
>> $ARCHes.
>>
>> [slab.h is the second most used header file after module.h; kernel.h
>> is right there with slab.h. There could be some minor error in the
>> counting due to some #includes having comments after them and I
>> didn't combine all of those.]
>>
>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>> header files).
>>
>> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
> 
> I threw it at a random selection of configs and so far the only failures
> I'm seeing are:
> 
>   lib/test_firmware.c:134:2: error: implicit declaration of function 'vfree' 
> [-Werror=implicit-function-declaration]   
>
>   lib/test_firmware.c:620:25: error: implicit declaration of function 
> 'vzalloc' [-Werror=implicit-function-declaration]
>   lib/test_firmware.c:620:2: error: implicit declaration of function 
> 'vzalloc' [-Werror=implicit-function-declaration]
>   security/integrity/digsig.c:146:2: error: implicit declaration of function 
> 'vfree' [-Werror=implicit-function-declaration]
> 
> Full results trickling in here, not all the failures there are caused by
> this patch, ie. some configs are broken in mainline:
> 
>   http://kisskb.ellerman.id.au/kisskb/head/13396/

That's very useful, thanks.

I'll send a few patches for those.

-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] headers: untangle kmemleak.h from mm.h

2018-02-12 Thread Randy Dunlap
On 02/12/2018 04:28 AM, Michael Ellerman wrote:
> Randy Dunlap <rdun...@infradead.org> writes:
> 
>> From: Randy Dunlap <rdun...@infradead.org>
>>
>> Currently  #includes  for no obvious
>> reason. It looks like it's only a convenience, so remove kmemleak.h
>> from slab.h and add  to any users of kmemleak_*
>> that don't already #include it.
>> Also remove  from source files that do not use it.
>>
>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>> would be good to run it through the 0day bot for other $ARCHes.
>> I have neither the horsepower nor the storage space for the other
>> $ARCHes.
>>
>> [slab.h is the second most used header file after module.h; kernel.h
>> is right there with slab.h. There could be some minor error in the
>> counting due to some #includes having comments after them and I
>> didn't combine all of those.]
>>
>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>> header files).
>>
>> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
> 
> I threw it at a random selection of configs and so far the only failures
> I'm seeing are:
> 
>   lib/test_firmware.c:134:2: error: implicit declaration of function 'vfree' 
> [-Werror=implicit-function-declaration]   
>
>   lib/test_firmware.c:620:25: error: implicit declaration of function 
> 'vzalloc' [-Werror=implicit-function-declaration]
>   lib/test_firmware.c:620:2: error: implicit declaration of function 
> 'vzalloc' [-Werror=implicit-function-declaration]
>   security/integrity/digsig.c:146:2: error: implicit declaration of function 
> 'vfree' [-Werror=implicit-function-declaration]
> 

Both of those source files need to #include .

> Full results trickling in here, not all the failures there are caused by
> this patch, ie. some configs are broken in mainline:
> 
>   http://kisskb.ellerman.id.au/kisskb/head/13396/
> 
> cheers

:)

-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] headers: untangle kmemleak.h from mm.h

2018-02-11 Thread Randy Dunlap
From: Randy Dunlap <rdun...@infradead.org>

Currently  #includes  for no obvious
reason. It looks like it's only a convenience, so remove kmemleak.h
from slab.h and add  to any users of kmemleak_*
that don't already #include it.
Also remove  from source files that do not use it.

This is tested on i386 allmodconfig and x86_64 allmodconfig. It
would be good to run it through the 0day bot for other $ARCHes.
I have neither the horsepower nor the storage space for the other
$ARCHes.

[slab.h is the second most used header file after module.h; kernel.h
is right there with slab.h. There could be some minor error in the
counting due to some #includes having comments after them and I
didn't combine all of those.]

This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
header files).

Signed-off-by: Randy Dunlap <rdun...@infradead.org>
---

Fengguang, can you have this patch run thru 0day builds, please?

 arch/powerpc/sysdev/dart_iommu.c  |1 +
 arch/powerpc/sysdev/msi_bitmap.c  |1 +
 arch/s390/kernel/nmi.c|2 +-
 arch/s390/kernel/smp.c|1 -
 arch/sparc/kernel/irq_64.c|1 -
 arch/x86/kernel/pci-dma.c |1 -
 drivers/iommu/exynos-iommu.c  |1 +
 drivers/iommu/mtk_iommu_v1.c  |1 -
 drivers/net/ethernet/ti/cpsw.c|1 +
 drivers/net/wireless/realtek/rtlwifi/pci.c|1 -
 drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c |1 -
 drivers/staging/rtl8188eu/hal/fw.c|2 +-
 drivers/staging/rtlwifi/pci.c |1 -
 drivers/virtio/virtio_ring.c  |1 -
 include/linux/slab.h  |1 -
 kernel/ucount.c   |1 +
 mm/cma.c  |1 +
 mm/memblock.c |1 +
 net/core/sysctl_net_core.c|1 -
 net/ipv4/route.c  |1 -
 security/apparmor/lsm.c   |1 -
 21 files changed, 9 insertions(+), 14 deletions(-)

--- lnx-416-rc1.orig/include/linux/slab.h
+++ lnx-416-rc1/include/linux/slab.h
@@ -125,7 +125,6 @@
 #define ZERO_OR_NULL_PTR(x) ((unsigned long)(x) <= \
(unsigned long)ZERO_SIZE_PTR)
 
-#include 
 #include 
 
 struct mem_cgroup;
--- lnx-416-rc1.orig/kernel/ucount.c
+++ lnx-416-rc1/kernel/ucount.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define UCOUNTS_HASHTABLE_BITS 10
--- lnx-416-rc1.orig/mm/memblock.c
+++ lnx-416-rc1/mm/memblock.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
--- lnx-416-rc1.orig/mm/cma.c
+++ lnx-416-rc1/mm/cma.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "cma.h"
--- lnx-416-rc1.orig/drivers/staging/rtl8188eu/hal/fw.c
+++ lnx-416-rc1/drivers/staging/rtl8188eu/hal/fw.c
@@ -30,7 +30,7 @@
 #include "rtl8188e_hal.h"
 
 #include 
-#include 
+#include 
 
 static void _rtl88e_enable_fw_download(struct adapter *adapt, bool enable)
 {
--- lnx-416-rc1.orig/drivers/iommu/exynos-iommu.c
+++ lnx-416-rc1/drivers/iommu/exynos-iommu.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/arch/s390/kernel/nmi.c
+++ lnx-416-rc1/arch/s390/kernel/nmi.c
@@ -15,7 +15,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/arch/powerpc/sysdev/dart_iommu.c
+++ lnx-416-rc1/arch/powerpc/sysdev/dart_iommu.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/arch/powerpc/sysdev/msi_bitmap.c
+++ lnx-416-rc1/arch/powerpc/sysdev/msi_bitmap.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/drivers/net/ethernet/ti/cpsw.c
+++ lnx-416-rc1/drivers/net/ethernet/ti/cpsw.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
--- lnx-416-rc1.orig/drivers/virtio/virtio_ring.c
+++ lnx-416-rc1/drivers/virtio/virtio_ring.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
--- lnx-416-rc1.orig/security/apparmor/lsm.c
+++ lnx-416-rc1/security/apparmor/lsm.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "include/apparmor.h"
--- lnx-416-rc1.orig/drivers/iommu/mtk_iommu_v1.c
+++ lnx-416-rc1/drivers/iommu/mtk_iommu_v1.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/drivers/

Re: [PATCH 22/34] dma-mapping: add an arch_dma_supported hook

2018-02-02 Thread Randy Dunlap
On 01/12/2018 12:42 AM, Christoph Hellwig wrote:
> To implement the x86 forbid_dac and iommu_sac_force we want an arch hook
> so that it can apply the global options across all dma_map_ops
> implementations.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/x86/include/asm/dma-mapping.h |  3 +++
>  arch/x86/kernel/pci-dma.c  | 19 ---
>  include/linux/dma-mapping.h| 11 +++
>  3 files changed, 26 insertions(+), 7 deletions(-)

> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 88bcb1a8211d..d67742dad904 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -576,6 +576,14 @@ static inline int dma_mapping_error(struct device *dev, 
> dma_addr_t dma_addr)
>   return 0;
>  }
>  
> +/*
> + * This is a hack for the legacy x86 forbid_dac and iommu_sac_force. Please
> + * don't use this is new code.

 in new code.

> + */
> +#ifndef arch_dma_supported
> +#define arch_dma_supported(dev, mask)(1)
> +#endif


-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

2017-10-15 Thread Randy Dunlap
On 10/15/17 20:29, Randy Dunlap wrote:
> On 10/15/17 20:27, Randy Dunlap wrote:
>> On 10/15/17 19:27, Marian Mihailescu wrote:
>>> After commit 7844572c633964c864d9f32dc3f2a8ffe5d70371, dma_noop_ops
>>> are built only for architectures that use it.
>>>
>>> For ARM architecture, CONFIG_DMA_NOOP_OPS is not selected, and cannot
>>> be selected.

What kernel version are you looking at?
I see that it is selected:

--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -22,6 +22,7 @@ config ARM
select CLONE_BACKWARDS
select CPU_PM if (SUSPEND || CPU_IDLE)
select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS
+   select DMA_NOOP_OPS if !MMU
select EDAC_SUPPORT
select EDAC_ATOMIC_SCRUB
select GENERIC_ALLOCATOR


That's in commit ID 1c51c429f30ea10428337f3a33c12059ba59f668 from May 24, 2017.

>>> However, arch/arm/include/asm/dma-mapping.h is referencing dma_noop_ops:
>>>
>>> static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type 
>>> *bus)
>>> {
>>> return IS_ENABLED(CONFIG_MMU) ? _dma_ops : _noop_ops;
>>> }
>>>
>>> I will let a maintainer suggest the best resolution for this :)
>>>
>>
>> add Bart and iommu mailing list.
>>
> 
> and add Vladimir.
> 
> 


-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

2017-10-15 Thread Randy Dunlap
On 10/15/17 20:27, Randy Dunlap wrote:
> On 10/15/17 19:27, Marian Mihailescu wrote:
>> After commit 7844572c633964c864d9f32dc3f2a8ffe5d70371, dma_noop_ops
>> are built only for architectures that use it.
>>
>> For ARM architecture, CONFIG_DMA_NOOP_OPS is not selected, and cannot
>> be selected.
>>
>> However, arch/arm/include/asm/dma-mapping.h is referencing dma_noop_ops:
>>
>> static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type 
>> *bus)
>> {
>> return IS_ENABLED(CONFIG_MMU) ? _dma_ops : _noop_ops;
>> }
>>
>> I will let a maintainer suggest the best resolution for this :)
>>
> 
> add Bart and iommu mailing list.
> 

and add Vladimir.


-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: CONFIG_DMA_NOOP_OPS breaks ARM arch

2017-10-15 Thread Randy Dunlap
On 10/15/17 19:27, Marian Mihailescu wrote:
> After commit 7844572c633964c864d9f32dc3f2a8ffe5d70371, dma_noop_ops
> are built only for architectures that use it.
> 
> For ARM architecture, CONFIG_DMA_NOOP_OPS is not selected, and cannot
> be selected.
> 
> However, arch/arm/include/asm/dma-mapping.h is referencing dma_noop_ops:
> 
> static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
> {
> return IS_ENABLED(CONFIG_MMU) ? _dma_ops : _noop_ops;
> }
> 
> I will let a maintainer suggest the best resolution for this :)
> 

add Bart and iommu mailing list.


-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2] iommu: exynos: Fix trivial typos

2014-08-04 Thread Randy Dunlap
On 08/03/14 21:36, Sachin Kamat wrote:
 Fixed trivial typos and grammar to improve readability.
 Changed w/a to workaround.
 
 Signed-off-by: Sachin Kamat sachin.ka...@samsung.com
 ---
  drivers/iommu/exynos-iommu.c | 51 
 ++--
  1 file changed, 26 insertions(+), 25 deletions(-)

Acked-by: Randy Dunlap rdun...@infradead.org

Thanks.

-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/1] iommu: exynos: Fix trivial typos

2014-08-02 Thread Randy Dunlap
On 08/01/14 23:03, Sachin Kamat wrote:
 Fixed trivial typos and grammar to improve readability.
 
 Signed-off-by: Sachin Kamat sachin.ka...@samsung.com
 ---
  drivers/iommu/exynos-iommu.c | 22 +++---
  1 file changed, 11 insertions(+), 11 deletions(-)
 
 diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
 index d037e87..327ebec 100644
 --- a/drivers/iommu/exynos-iommu.c
 +++ b/drivers/iommu/exynos-iommu.c
 @@ -32,7 +32,7 @@
  typedef u32 sysmmu_iova_t;
  typedef u32 sysmmu_pte_t;
  
 -/* We does not consider super section mapping (16MB) */
 +/* We do not consider super section mapping (16MB) */
  #define SECT_ORDER 20
  #define LPAGE_ORDER 16
  #define SPAGE_ORDER 12
 @@ -307,7 +307,7 @@ static void show_fault_information(const char *name,
  
  static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
  {
 - /* SYSMMU is in blocked when interrupt occurred. */
 + /* SYSMMU is in blocked state when interrupt occurred. */
   struct sysmmu_drvdata *data = dev_id;
   enum exynos_sysmmu_inttype itype;
   sysmmu_iova_t addr = -1;
 @@ -567,8 +567,8 @@ static void sysmmu_tlb_invalidate_entry(struct device 
 *dev, sysmmu_iova_t iova,
   /*
* L2TLB invalidation required
* 4KB page: 1 invalidation
 -  * 64KB page: 16 invalidation
 -  * 1MB page: 64 invalidation
 +  * 64KB page: 16 invalidations
 +  * 1MB page: 64 invalidations
* because it is set-associative TLB
* with 8-way and 64 sets.
* 1MB page can be cached in one of all sets.
 @@ -862,13 +862,13 @@ static sysmmu_pte_t *alloc_lv2entry(struct 
 exynos_iommu_domain *priv,
  
   /*
* If pretched SLPD is a fault SLPD in zero_l2_table, FLPD cache

What is   pretched ?

 -  * may caches the address of zero_l2_table. This function
 +  * may cache the address of zero_l2_table. This function
* replaces the zero_l2_table with new L2 page table to write
* valid mappings.
* Accessing the valid area may cause page fault since FLPD
 -  * cache may still caches zero_l2_table for the valid area
 +  * cache may still cache zero_l2_table for the valid area
* instead of new L2 page table that have the mapping

 has

 -  * information of the valid area
 +  * information of the valid area.
* Thus any replacement of zero_l2_table with other valid L2
* page table must involve FLPD cache invalidation for System
* MMU v3.3.
 @@ -963,14 +963,14 @@ static int lv2set_page(sysmmu_pte_t *pent, phys_addr_t 
 paddr, size_t size,
  /*
   * *CAUTION* to the I/O virtual memory managers that support exynos-iommu:
   *
 - * System MMU v3.x have an advanced logic to improve address translation
 + * System MMU v3.x has an advanced logic to improve address translation

  drop:   an
just say: has advanced logic

   * performance with caching more page table entries by a page table walk.
   * However, the logic has a bug that caching fault page table entries and 
 System
   * MMU reports page fault if the cached fault entry is hit even though the 
 fault
   * entry is updated to a valid entry after the entry is cached.
   * To prevent caching fault page table entries which may be updated to valid
   * entries later, the virtual memory manager should care about the w/a about 
 the
 - * problem. The followings describe w/a.
 + * problem. The following describes w/a.
   *

Please change all w/a to workaround.
It took me a while to figure out what w/a means.

   * Any two consecutive I/O virtual address regions must have a hole of 128KiB
   * in maximum to prevent misbehavior of System MMU 3.x. (w/a of h/w bug)
 @@ -982,8 +982,8 @@ static int lv2set_page(sysmmu_pte_t *pent, phys_addr_t 
 paddr, size_t size,
   *
   * Because System MMU v3.3 caches page table entries more aggressively, it 
 needs
   * more w/a.
 - * - Any two consecutive I/O virtual regions must be have a hole of larger 
 size
 - *   than or equal size to 128KiB.
 + * - Any two consecutive I/O virtual regions must be have a hole of size 
 larger

must have a hole

 + *   than or equal to 128KiB.
   * - Start address of an I/O virtual region must be aligned by 128KiB.
   */
  static int exynos_iommu_map(struct iommu_domain *domain, unsigned long 
 l_iova,
 


-- 
~Randy
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu