[RFC][PATCH 5/5] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module

2020-06-15 Thread John Stultz
Allow the qcom_scm driver to be loadable as a permenent module. Cc: Andy Gross Cc: Bjorn Andersson Cc: Joerg Roedel Cc: Thomas Gleixner Cc: Jason Cooper Cc: Marc Zyngier Cc: Linus Walleij Cc: Lina Iyer Cc: Saravana Kannan Cc: Todd Kjos Cc: Greg Kroah-Hartman Cc: linux-arm-...@vger.kerne

[RFC][PATCH 2/5] irq: irqchip: Export irq_chip_retrigger_hierarchy and irq_chip_set_vcpu_affinity_parent

2020-06-15 Thread John Stultz
Add EXPORT_SYMBOL_GPL entries for irq_chip_retrigger_hierarchy() and irq_chip_set_vcpu_affinity_parent() so that we can allow drivers like the qcom-pdc driver to be loadable as a module. Cc: Andy Gross Cc: Bjorn Andersson Cc: Joerg Roedel Cc: Thomas Gleixner Cc: Jason Cooper Cc: Marc Zyngier

[RFC][PATCH 0/5] Allow for qcom-pdc, pinctrl-msm and qcom-scm drivers to be loadable as modules

2020-06-15 Thread John Stultz
This patch series provides exports and config tweaks to allow the qcom-pdc, pinctrl-msm and qcom-scm drivers to be able to be configured as permement modules (particularlly useful for the Android Generic Kernel Image efforts). Feedback would be appreciated! thanks -john Cc: Andy Gross Cc: Bjorn

[RFC][PATCH 1/5] irq: irqdomain: Export irq_domain_update_bus_token

2020-06-15 Thread John Stultz
Add export for irq_domain_update_bus_token() so that we can allow drivers like the qcom-pdc driver to be loadable as a module. Cc: Andy Gross Cc: Bjorn Andersson Cc: Joerg Roedel Cc: Thomas Gleixner Cc: Jason Cooper Cc: Marc Zyngier Cc: Linus Walleij Cc: Lina Iyer Cc: Saravana Kannan Cc:

[RFC][PATCH 4/5] pinctrl: qcom: Allow pinctrl-msm code to be loadable as a module

2020-06-15 Thread John Stultz
Tweaks to allow pinctrl-msm code to be loadable as a module. This is needed in order to support having the qcom-scm driver, which pinctrl-msm calls into, configured as a module. Cc: Andy Gross Cc: Bjorn Andersson Cc: Joerg Roedel Cc: Thomas Gleixner Cc: Jason Cooper Cc: Marc Zyngier Cc: Linu

[RFC][PATCH 3/5] irqchip: Allow QCOM_PDC to be loadable as a perment module

2020-06-15 Thread John Stultz
Allows qcom-pdc driver to be loaded as a permenent module Also, due to the fact that IRQCHIP_DECLARE becomes a no-op when building as a module, we have to add the platform driver hooks explicitly. Thanks to Saravana for his help on pointing out the IRQCHIP_DECLARE issue and guidance on a solution

Re: [PATCH v3 3/7] iommu/mediatek: Disable STANDARD_AXI_MODE in MISC_CTRL

2020-06-15 Thread chao hao
On Mon, 2020-05-25 at 14:14 +0800, Yong Wu wrote: > On Sat, 2020-05-09 at 16:36 +0800, Chao Hao wrote: > > In order to improve performance, we always disable STANDARD_AXI_MODE in > > MISC_CTRL. > > > > Signed-off-by: Chao Hao > > --- > > drivers/iommu/mtk_iommu.c | 8 +++- > > drivers/iommu/

Re: [PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-15 Thread Greg Kroah-Hartman
On Mon, Jun 15, 2020 at 06:17:42PM -0700, Rajat Jain wrote: > This is needed to allow the userspace to determine when an untrusted > device has been added, and thus allowing it to bind the driver manually > to it, if it so wishes. This is being done as part of the approach > discussed at https://lk

RE: [PATCH v2 00/15] vfio: expose virtual Shared Virtual Addressing to VMs

2020-06-15 Thread Tian, Kevin
> From: Stefan Hajnoczi > Sent: Monday, June 15, 2020 6:02 PM > > On Thu, Jun 11, 2020 at 05:15:19AM -0700, Liu Yi L wrote: > > Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on > > Intel platforms allows address space sharing between device DMA and > > applications. SVA can

RE: [PATCH v2 02/15] iommu: Report domain nesting info

2020-06-15 Thread Liu, Yi L
> From: Tian, Kevin > Sent: Tuesday, June 16, 2020 9:56 AM > > > From: Liu, Yi L > > Sent: Monday, June 15, 2020 2:05 PM > > > > Hi Kevin, > > > > > From: Tian, Kevin > > > Sent: Monday, June 15, 2020 9:23 AM > > > > > > > From: Liu, Yi L > > > > Sent: Friday, June 12, 2020 5:05 PM > > > > > >

RE: [PATCH v2 02/15] iommu: Report domain nesting info

2020-06-15 Thread Tian, Kevin
> From: Liu, Yi L > Sent: Monday, June 15, 2020 2:05 PM > > Hi Kevin, > > > From: Tian, Kevin > > Sent: Monday, June 15, 2020 9:23 AM > > > > > From: Liu, Yi L > > > Sent: Friday, June 12, 2020 5:05 PM > > > > > > Hi Alex, > > > > > > > From: Alex Williamson > > > > Sent: Friday, June 12, 202

[PATCH 2/4] pci: set "untrusted" flag for truly external devices only

2020-06-15 Thread Rajat Jain via iommu
The "ExternalFacing" devices (root ports) are still internal devices that sit on the internal system fabric and thus trusted. Currently they were being marked untrusted - likely as an unintended border case. This patch uses the platform flag to identify the external facing devices and then use it

[PATCH 4/4] pci: export untrusted attribute in sysfs

2020-06-15 Thread Rajat Jain via iommu
This is needed to allow the userspace to determine when an untrusted device has been added, and thus allowing it to bind the driver manually to it, if it so wishes. This is being done as part of the approach discussed at https://lkml.org/lkml/2020/6/9/1331 Signed-off-by: Rajat Jain --- drivers/p

[PATCH 1/4] pci: Keep the ACS capability offset in device

2020-06-15 Thread Rajat Jain via iommu
Currently this is being looked up at a number of places. Read and store it once at bootup so that it can be used by all later. Signed-off-by: Rajat Jain --- drivers/pci/p2pdma.c | 2 +- drivers/pci/pci.c| 21 + drivers/pci/pci.h| 2 +- drivers/pci/probe.c | 2 +-

[PATCH 3/4] pci: acs: Enable PCI_ACS_TB for untrusted/external-facing devices

2020-06-15 Thread Rajat Jain via iommu
When enabling ACS, currently the bit "translation blocking" was not getting changed at all. Set it to disable translation blocking too for all external facing or untrusted devices. This is OK because ATS is only allowed on internal devces. Signed-off-by: Rajat Jain --- drivers/pci/pci.c| 4

Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU

2020-06-15 Thread Bjorn Helgaas
On Sat, Jun 13, 2020 at 10:30:56PM +0800, Zhangfei Gao wrote: > On 2020/6/11 下午9:44, Bjorn Helgaas wrote: > > +++ b/drivers/iommu/iommu.c > > > > > > > > > > @@ -2418,6 +2418,10 @@ int iommu_fwspec_init(struct device > > > > > > > > > > *dev, struct > > > > > > > > > > fwnode_handle *iommu_fwnode,

Re: [PATCH v2 04/12] docs: x86: Add documentation for SVA (Shared Virtual Addressing)

2020-06-15 Thread Fenghua Yu
Hi, Baolu, On Sat, Jun 13, 2020 at 08:17:40PM +0800, Lu Baolu wrote: > Hi Fenghua, > > On 2020/6/13 8:41, Fenghua Yu wrote: > >+implement implement fairness or ensure forward progress can be made. > > Repeated "implement". Will fix this. > >+For example, the Intel Data Streaming Accelerator (D

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Andy Lutomirski
> On Jun 15, 2020, at 1:17 PM, Fenghua Yu wrote: > > Hi, Peter, > >> On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote: >>> On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote: >>> >>> Or do you suggest to add a random new flag in struct thread_info instead >>> of a TIF fl

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
On Mon, Jun 15, 2020 at 01:17:35PM -0700, Fenghua Yu wrote: > Hi, Peter, > > On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote: > > On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote: > > > > > Or do you suggest to add a random new flag in struct thread_info instead > > > of

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Andy Lutomirski
> On Jun 15, 2020, at 1:56 PM, Luck, Tony wrote: > >  >> >> Are we planning to keep PASID live once a task has used it once or are we >> going to swap it lazily? If the latter, a percpu variable might be better. > > Current plan is "touch it once and the task owns it until exit(2)" > > Ma

RE: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Luck, Tony
> So what’s the RDMSR for? Surely you > have some state somewhere that says “this task has a PASID.” > Can’t you just make sure that stays in sync with the MSR? Then, on #GP, if > the task already has a PASID, you know the MSR is set. We have state that says the process ("mm") has been allocate

RE: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Luck, Tony
> Are we planning to keep PASID live once a task has used it once or are we > going to swap it lazily? If the latter, a percpu variable might be better. Current plan is "touch it once and the task owns it until exit(2)" Maybe someday in the future when we have data on how applications actually

Re: [PATCH] iommu/amd: Fix event counter availability check

2020-06-15 Thread Alexander Monakov
On Mon, 1 Jun 2020, Suravee Suthikulpanit wrote: > Alexander > > On 6/1/20 4:01 PM, Alexander Monakov wrote: > > On Mon, 1 Jun 2020, Suravee Suthikulpanit wrote: > > > > > > Moving init_iommu_perf_ctr just after iommu_flush_all_caches resolves > > > > the issue. This is the earliest point in amd

Re: [PATCH 26/29] docs: fix references for DMA*.txt files

2020-06-15 Thread Paul E. McKenney
On Mon, Jun 15, 2020 at 08:47:05AM +0200, Mauro Carvalho Chehab wrote: > As we moved those files to core-api, fix references to point > to their newer locations. > > Signed-off-by: Mauro Carvalho Chehab > --- > Documentation/PCI/pci.rst | 6 +++--- > Documentation/block

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Fenghua Yu
Hi, Peter, On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote: > On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote: > > > Or do you suggest to add a random new flag in struct thread_info instead > > of a TIF flag? > > Why thread_info? What's wrong with something simple like

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote: > Or do you suggest to add a random new flag in struct thread_info instead > of a TIF flag? Why thread_info? What's wrong with something simple like the below. It takes a bit from the 'strictly current' flags word. diff --git a/include

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Fenghua Yu
Hi, Peter, On Mon, Jun 15, 2020 at 08:31:16PM +0200, Peter Zijlstra wrote: > On Mon, Jun 15, 2020 at 11:12:59AM -0700, Fenghua Yu wrote: > > > I don't get why you need a rdmsr here, or why not having one would > > > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed? > > > > My

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
On Mon, Jun 15, 2020 at 11:12:59AM -0700, Fenghua Yu wrote: > > I don't get why you need a rdmsr here, or why not having one would > > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed? > > My concern is TIF flags are precious (only 3 slots available). Defining > a new TIF flag

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
On Mon, Jun 15, 2020 at 11:19:21AM -0700, Raj, Ashok wrote: > On Mon, Jun 15, 2020 at 06:03:57PM +0200, Peter Zijlstra wrote: > > > > I don't get why you need a rdmsr here, or why not having one would > > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed? > > > > > > > + *

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Raj, Ashok
On Mon, Jun 15, 2020 at 06:03:57PM +0200, Peter Zijlstra wrote: > > I don't get why you need a rdmsr here, or why not having one would > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed? > > > > > +*/ > > > > + rdmsrl(MSR_IA32_PASID, pasid_msr); > > > > + i

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Fenghua Yu
On Mon, Jun 15, 2020 at 06:03:57PM +0200, Peter Zijlstra wrote: > On Mon, Jun 15, 2020 at 08:48:54AM -0700, Fenghua Yu wrote: > > Hi, Peter, > > On Mon, Jun 15, 2020 at 09:56:49AM +0200, Peter Zijlstra wrote: > > > On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote: > > > > +/* > > > > + *

RE: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Luck, Tony
>> The heuristic always initializes the MSR with the per mm PASID IIF the >> mm has a valid PASID but the MSR doesn't have one. This heuristic usually >> happens only once on the first #GP in a thread. > > But it doesn't guarantee the PASID is the right one. Suppose both the mm > has a PASID and th

Re: [PATCH v2] iommu/tegra-smmu: Add missing locks around mapping operations

2020-06-15 Thread Dmitry Osipenko
25.05.2020 22:54, Dmitry Osipenko пишет: > The mapping operations of the Tegra SMMU driver are subjected to a race > condition issues because SMMU Address Space isn't allocated and freed > atomically, while it should be. This patch makes the mapping operations > atomic, it fixes an accidentally rel

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
On Mon, Jun 15, 2020 at 08:48:54AM -0700, Fenghua Yu wrote: > Hi, Peter, > On Mon, Jun 15, 2020 at 09:56:49AM +0200, Peter Zijlstra wrote: > > On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote: > > > +/* > > > + * Apply some heuristics to see if the #GP fault was caused by a thread > > > +

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Fenghua Yu
Hi, Peter, On Mon, Jun 15, 2020 at 09:56:49AM +0200, Peter Zijlstra wrote: > On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote: > > +/* > > + * Apply some heuristics to see if the #GP fault was caused by a thread > > + * that hasn't had the IA32_PASID MSR initialized. If it looks like tha

Re: [PATCH v2 00/12] x86: tag application address space for devices

2020-06-15 Thread Fenghua Yu
Hi, Peter, On Mon, Jun 15, 2020 at 09:52:02AM +0200, Peter Zijlstra wrote: > On Fri, Jun 12, 2020 at 05:41:21PM -0700, Fenghua Yu wrote: > > > This series only provides simple and basic support for ENQCMD and the MSR: > > 1. Clean up type definitions (patch 1-3). These patches can be in a > >s

Re: [PATCH 2/2] iommu/amd: Move Kconfig and Makefile bits down into amd directory

2020-06-15 Thread Suravee Suthikulpanit
Reviewed-by: Suravee Suthikulpanit Thanks, Suravee On 6/13/20 6:11 AM, Jerry Snitselaar wrote: Move AMD Kconfig and Makefile bits down into the amd directory with the rest of the AMD specific files. Cc: Joerg Roedel Cc: Suravee Suthikulpanit Signed-off-by: Jerry Snitselaar --- drivers/io

[PATCH] uacce: remove uacce_vma_fault

2020-06-15 Thread Zhangfei Gao
Fix NULL pointer error if removing uacce's parent module during app's running. SIGBUS is already reported by do_page_fault, so uacce_vma_fault is not needed. If providing vma_fault, vmf->page has to be filled as well, required by __do_fault. Reported-by: Jean-Philippe Brucker Signed-off-by: Zhang

RE: [PATCH v2 00/15] vfio: expose virtual Shared Virtual Addressing to VMs

2020-06-15 Thread Liu, Yi L
> From: Stefan Hajnoczi > Sent: Monday, June 15, 2020 6:02 PM > > On Thu, Jun 11, 2020 at 05:15:19AM -0700, Liu Yi L wrote: > > Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on > > Intel platforms allows address space sharing between device DMA and > > applications. SVA can

[Issue]platform/x86: iommu: System can't shutdown because iommu driver keeps checking the status of DMA_GSTS_TES

2020-06-15 Thread Koba Ko
hi All, I have a machine and there's only intel gpu. the secureboot and vt-d is enabled in BIOS. On the Ubuntu desktop, I do s2idle first and restart the machine. The machine can't restart successfully, so I need to press the power button to shutdown. I tried each of the following and the issue ca

[Issue]platform/x86: iommu: System can't shutdown because iommu driver keeps checking the status of DMA_GSTS_TES

2020-06-15 Thread Koba Ko
hi All, I have a machine and there's only intel gpu. the secureboot and vt-d is enabled in BIOS. On the Ubuntu desktop, I do s2idle first and restart the machine. The machine can't restart successfully, so I need to press the power button to shutdown. I tried each of the following and the issue ca

Re: [PATCH v2 00/15] vfio: expose virtual Shared Virtual Addressing to VMs

2020-06-15 Thread Stefan Hajnoczi
On Thu, Jun 11, 2020 at 05:15:19AM -0700, Liu Yi L wrote: > Shared Virtual Addressing (SVA), a.k.a, Shared Virtual Memory (SVM) on > Intel platforms allows address space sharing between device DMA and > applications. SVA can reduce programming complexity and enhance security. > > This VFIO series

Re: [PATCH v2 14/15] vfio: Document dual stage control

2020-06-15 Thread Stefan Hajnoczi
On Thu, Jun 11, 2020 at 05:15:33AM -0700, Liu Yi L wrote: > From: Eric Auger > > The VFIO API was enhanced to support nested stage control: a bunch of > new iotcls and usage guideline. > > Let's document the process to follow to set up nested mode. > > Cc: Kevin Tian > CC: Jacob Pan > Cc: Ale

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote: > +/* > + * Apply some heuristics to see if the #GP fault was caused by a thread > + * that hasn't had the IA32_PASID MSR initialized. If it looks like that > + * is the problem, try initializing the IA32_PASID MSR. If the heuristic > + *

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Peter Zijlstra
On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote: > @@ -447,6 +458,18 @@ dotraplinkage void do_general_protection(struct pt_regs > *regs, long error_code) > int ret; > > RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU"); > + > + /* > + * Perform th

Re: [PATCH v2 00/12] x86: tag application address space for devices

2020-06-15 Thread Peter Zijlstra
On Fri, Jun 12, 2020 at 05:41:21PM -0700, Fenghua Yu wrote: > This series only provides simple and basic support for ENQCMD and the MSR: > 1. Clean up type definitions (patch 1-3). These patches can be in a >separate series. >- Define "pasid" as "unsigned int" consistently (patch 1 and 2).

Re: arm64 iommu groups issue

2020-06-15 Thread John Garry
On 12/06/2020 15:30, Lorenzo Pieralisi wrote: On Mon, Feb 17, 2020 at 12:08:48PM +, John Garry wrote: Right, and even worse is that it relies on the port driver even existing at all. All this iommu group assignment should be taken outside device driver probe paths. However we could still

Re: [Issue]platform/x86: iommu: System can't shutdown because iommu driver keeps checking the status of DMA_GSTS_TES

2020-06-15 Thread Lu Baolu
Hi Koba Ko, On 2020/6/15 11:19, Koba Ko wrote: hi All, I have a machine and there's only intel gpu. the secureboot and vt-d is enabled in BIOS. On the Ubuntu desktop, I do s2idle first and restart the machine. The machine can't restart successfully, so I need to press the power button to shutdo

[PATCH] dma-direct: enable mmap for !CONFIG_MMU

2020-06-15 Thread Christoph Hellwig
nommu configfs can trivially map the coherent allocations to user space, as no actual page table setup is required and the kernel and the user space programs share the same address space. Fixes: 62fcee9a3bd7 ("dma-mapping: remove CONFIG_ARCH_NO_COHERENT_DMA_MMAP") Signed-off-by: Christoph Hellwig

Re: [patch for-5.8 4/4] dma-direct: add missing set_memory_decrypted() for coherent mapping

2020-06-15 Thread Christoph Hellwig
On Thu, Jun 11, 2020 at 12:20:32PM -0700, David Rientjes wrote: > When a coherent mapping is created in dma_direct_alloc_pages(), it needs > to be decrypted if the device requires unencrypted DMA before returning. > > Fixes: 3acac065508f ("dma-mapping: merge the generic remapping helpers > into dm