Re: [PATCH v7 2/3] PCI: Add support for PCI inbound windows resources

On Mon, May 22, 2017 at 11:39 AM, Oza Pawandeep wrote: > This patch adds support for inbound memory window > for PCI RC drivers. > > It defines new function pci_create_root_bus2 which > takes inbound resources as an argument and fills in the > memory resource to PCI internal

Re: Device address specific mapping of arm,mmu-500

Hi Marc/Robin/Will, On 5/30/17 10:27 AM, Marc Zyngier wrote: > On 30/05/17 18:16, Ray Jui wrote: >> Hi Marc, >> >> On 5/30/17 9:59 AM, Marc Zyngier wrote: >>> On 30/05/17 17:49, Ray Jui wrote: Hi Will, On 5/30/17 8:14 AM, Will Deacon wrote: > On Mon, May 29, 2017 at 06:18:45PM

Re: [PATCH 0/2] Save and restore pci properties to support FLR

On Tue, May 30, 2017 at 09:25:47AM -0700, Ashok Raj wrote: > Resending Jean's patch so it can be included earlier than his large > SVM commits. Original patch https://patchwork.kernel.org/patch/9593891 > was ack'ed by Bjorn. Let's commit these separately since we need > functionality earlier. > >

Re: [PATCH 2/2] PCI: Save properties required to handle FLR for replay purposes.

On Tue, May 30, 2017 at 09:25:49AM -0700, Ashok Raj wrote: > From: CQ Tang > > Requires: https://patchwork.kernel.org/patch/9593891 > > > After a FLR, pci-states need to be restored. This patch saves PASID features > and PRI reqs cached. > > To: Bjorn Helgaas

Re: [PATCH v5 26/32] x86, drm, fbdev: Do not specify encrypted memory for video mappings

On 5/16/2017 12:35 PM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 04:20:56PM -0500, Tom Lendacky wrote: Since video memory needs to be accessed decrypted, be sure that the memory encryption mask is not set for the video ranges. Signed-off-by: Tom Lendacky ---

Re: [PATCH 2/2] PCI: Save properties required to handle FLR for replay purposes.

On Tue, May 30, 2017 at 02:50:33PM -0500, Bjorn Helgaas wrote: > On Tue, May 30, 2017 at 09:25:49AM -0700, Ashok Raj wrote: > > From: CQ Tang > > > > Requires: https://patchwork.kernel.org/patch/9593891 > > The above patch (9593891) is not in my tree or Linus' tree, so I

Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

On 5/26/2017 11:35 AM, Borislav Petkov wrote: On Fri, May 26, 2017 at 11:22:36AM -0500, Tom Lendacky wrote: In addition to the same issue as efi.memmap.phys_map, efi_phys has the __initdata attribute so it will be released/freed which will cause problems in checks performed afterwards. Sounds

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

On 5/25/2017 11:17 PM, Xunlei Pang wrote: On 04/19/2017 at 05:21 AM, Tom Lendacky wrote: Provide support so that kexec can be used to boot a kernel when SME is enabled. Support is needed to allocate pages for kexec without encryption. This is needed in order to be able to reboot in the kernel

Re: [PATCH 1/2] PCI: Save properties required to handle FLR for replay purposes.

On Thu, May 11, 2017 at 11:50:24AM +0100, Jean-Philippe Brucker wrote: > Hi, > > On 10/05/17 19:39, Ashok Raj wrote: > > From: CQ Tang > > > > Requires: https://patchwork.kernel.org/patch/9593891 > > Since your series is likely to go in much earlier than my SVM mess, maybe >

[PATCH 0/2] Save and restore pci properties to support FLR

Resending Jean's patch so it can be included earlier than his large SVM commits. Original patch https://patchwork.kernel.org/patch/9593891 was ack'ed by Bjorn. Let's commit these separately since we need functionality earlier. Resending this series as requested by Jean. CQ Tang (1): PCI: Save

[PATCH 2/2] PCI: Save properties required to handle FLR for replay purposes.

From: CQ Tang Requires: https://patchwork.kernel.org/patch/9593891 After a FLR, pci-states need to be restored. This patch saves PASID features and PRI reqs cached. To: Bjorn Helgaas To: Joerg Roedel To: linux-...@vger.kernel.org To:

Re: [PATCH] iommu/amd: Propagate IOVA allocation failure

On 30/05/17 10:48, Joerg Roedel wrote: > On Fri, May 26, 2017 at 07:31:26PM +0100, Robin Murphy wrote: >> Unlike the old allocator, alloc_iova_fast() will return 0 if it failed >> to allocate a PFN. Since the callers of dma_ops_alloc_iova() would end >> up treating that as a valid address,

Re: Device address specific mapping of arm,mmu-500

On 30/05/17 18:16, Ray Jui wrote: > Hi Marc, > > On 5/30/17 9:59 AM, Marc Zyngier wrote: >> On 30/05/17 17:49, Ray Jui wrote: >>> Hi Will, >>> >>> On 5/30/17 8:14 AM, Will Deacon wrote: On Mon, May 29, 2017 at 06:18:45PM -0700, Ray Jui wrote: > I'm writing to check with you to see if the

Re: Device address specific mapping of arm,mmu-500

On 30/05/17 17:49, Ray Jui wrote: > Hi Will, > > On 5/30/17 8:14 AM, Will Deacon wrote: >> On Mon, May 29, 2017 at 06:18:45PM -0700, Ray Jui wrote: >>> I'm writing to check with you to see if the latest arm-smmu.c driver in >>> v4.12-rc Linux for smmu-500 can support mapping that is only specific

Re: Device address specific mapping of arm,mmu-500

Hi Marc, On 5/30/17 9:59 AM, Marc Zyngier wrote: > On 30/05/17 17:49, Ray Jui wrote: >> Hi Will, >> >> On 5/30/17 8:14 AM, Will Deacon wrote: >>> On Mon, May 29, 2017 at 06:18:45PM -0700, Ray Jui wrote: I'm writing to check with you to see if the latest arm-smmu.c driver in v4.12-rc

Re: Device address specific mapping of arm,mmu-500

On 30/05/17 17:49, Ray Jui wrote: > Hi Will, > > On 5/30/17 8:14 AM, Will Deacon wrote: >> On Mon, May 29, 2017 at 06:18:45PM -0700, Ray Jui wrote: >>> I'm writing to check with you to see if the latest arm-smmu.c driver in >>> v4.12-rc Linux for smmu-500 can support mapping that is only specific

Re: Device address specific mapping of arm,mmu-500

Hi Will, On 5/30/17 8:14 AM, Will Deacon wrote: > On Mon, May 29, 2017 at 06:18:45PM -0700, Ray Jui wrote: >> I'm writing to check with you to see if the latest arm-smmu.c driver in >> v4.12-rc Linux for smmu-500 can support mapping that is only specific to >> a particular physical address range

Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

On 5/21/2017 2:16 AM, Borislav Petkov wrote: On Fri, May 19, 2017 at 03:50:32PM -0500, Tom Lendacky wrote: The "worker" function would be doing the loop through the setup data, but since the setup data is mapped inside the loop I can't do the __init calling the non-init function and still hope

Re: [PATCH v5 29/32] x86/mm: Add support to encrypt the kernel in-place

On 5/26/2017 11:25 AM, Borislav Petkov wrote: On Thu, May 25, 2017 at 05:24:27PM -0500, Tom Lendacky wrote: I guess I could do that, but this will probably only end up clearing a single PGD entry anyway since it's highly doubtful the address range would cross a 512GB boundary. Or you can

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

On 5/19/2017 3:16 PM, Josh Poimboeuf wrote: On Fri, May 19, 2017 at 01:30:05PM +0200, Borislav Petkov wrote: it is called so early. I can get past it by adding: CFLAGS_mem_encrypt.o := $(nostackp) in the arch/x86/mm/Makefile, but that obviously eliminates the support for the whole file.

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

On 5/19/2017 6:30 AM, Borislav Petkov wrote: On Fri, Apr 21, 2017 at 01:56:13PM -0500, Tom Lendacky wrote: On 4/18/2017 4:22 PM, Tom Lendacky wrote: Add support to check if SME has been enabled and if memory encryption should be activated (checking of command line option based on the

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

On 5/30/2017 9:55 AM, Borislav Petkov wrote: > On Tue, May 30, 2017 at 09:38:36AM -0500, Tom Lendacky wrote: >> In this case we're running identity mapped and the "on" constant ends up >> as kernel address (0x81...) which results in a segfault. > > Would > > static const char

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

On Tue, May 30, 2017 at 09:38:36AM -0500, Tom Lendacky wrote: > In this case we're running identity mapped and the "on" constant ends up > as kernel address (0x81...) which results in a segfault. Would static const char *__on_str = "on"; ... if (!strncmp(buffer,

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

On 5/19/2017 6:27 AM, Borislav Petkov wrote: On Tue, Apr 18, 2017 at 04:22:23PM -0500, Tom Lendacky wrote: Add support to check if SME has been enabled and if memory encryption should be activated (checking of command line option based on the configuration of the default state). If memory

[PATCH v7 3/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #126

From: Geetha Sowjanya Cavium ThunderX2 SMMU doesn't support MSI and also doesn't have unique irq lines for gerror, eventq and cmdq-sync. This patch addresses the issue by checking if any interrupt sources are using same irq number, then they are registered as

[PATCH v7 2/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #74

From: Linu Cherian Cavium ThunderX2 SMMU implementation doesn't support page 1 register space and PAGE0_REGS_ONLY option is enabled as an errata workaround. This option when turned on, replaces all page 1 offsets used for EVTQ_PROD/CONS, PRIQ_PROD/CONS register access

[PATCH v7 1/3] ACPI/IORT: Fixup SMMUv3 resource size for Cavium ThunderX2 SMMUv3 model

From: Linu Cherian Cavium ThunderX2 implementation doesn't support second page in SMMU register space. Hence, resource size is set as 64k for this model. Signed-off-by: Linu Cherian Signed-off-by: Geetha Sowjanya

[PATCH v7 0/3] Cavium ThunderX2 SMMUv3 errata workarounds

Cavium ThunderX2 SMMUv3 implementation has two Silicon Erratas. 1. Errata ID #74 SMMU register alias Page 1 is not implemented 2. Errata ID #126 SMMU doesnt support unique IRQ lines and also MSI for gerror, eventq and cmdq-sync The following patchset does software workaround for these

Re: [PATCH v2] iommu/arm-smmu-v3: Increase CMDQ drain timeout value

Hi Sunil, On Mon, May 29, 2017 at 02:41:59PM +0530, Sunil Kovvuri wrote: > On Fri, May 5, 2017 at 4:47 PM, wrote: > > From: Sunil Goutham > > > > Processing queue full of TLB invalidation commands might > > take more time on some platforms than

Re: [PATCH 6/7] iommu/arm-smmu-v3: Add support for PCI ATS

On 30/05/17 11:28, Joerg Roedel wrote: > On Wed, May 24, 2017 at 07:01:42PM +0100, Jean-Philippe Brucker wrote: >> * TLB invalidation by range is batched and committed with a single sync. >> Batching ATC invalidation is inconvenient, endpoints limit the number of >> inflight invalidations.

Re: [PATCH 2/7] dt-bindings: PCI: Describe ATS property for root complex nodes

On 30/05/17 11:01, Joerg Roedel wrote: > On Wed, May 24, 2017 at 07:01:38PM +0100, Jean-Philippe Brucker wrote: >> +- ats-supported: if present, the root complex supports the Address >> + Translation Service (ATS). It is able to interpret the AT field in PCIe >> + Transaction Layer Packets, and

Re: [PATCH 6/7] iommu/arm-smmu-v3: Add support for PCI ATS

On Wed, May 24, 2017 at 07:01:42PM +0100, Jean-Philippe Brucker wrote: > * TLB invalidation by range is batched and committed with a single sync. > Batching ATC invalidation is inconvenient, endpoints limit the number of > inflight invalidations. We'd have to count the number of invalidations

Re: [PATCH 2/7] dt-bindings: PCI: Describe ATS property for root complex nodes

On Wed, May 24, 2017 at 07:01:38PM +0100, Jean-Philippe Brucker wrote: > +- ats-supported: if present, the root complex supports the Address > + Translation Service (ATS). It is able to interpret the AT field in PCIe > + Transaction Layer Packets, and forward Translation Completions or > +

Re: [PATCH] iommu/amd: Propagate IOVA allocation failure

On Fri, May 26, 2017 at 07:31:26PM +0100, Robin Murphy wrote: > Unlike the old allocator, alloc_iova_fast() will return 0 if it failed > to allocate a PFN. Since the callers of dma_ops_alloc_iova() would end > up treating that as a valid address, translate it to the DMA_ERROR_CODE > that they

Re: [PATCH] iommu/vt-d: unwrap __get_valid_domain_for_dev()

On Mon, May 22, 2017 at 06:28:51PM +0800, Peter Xu wrote: > We do find_domain() in __get_valid_domain_for_dev(), while we do the > same thing in get_valid_domain_for_dev(). No need to do it twice. > > Signed-off-by: Peter Xu > --- > drivers/iommu/intel-iommu.c | 16

Re: [PATCH v6 1/6] iommu: of: Fix check for returning EPROBE_DEFER

On Sat, May 27, 2017 at 07:17:40PM +0530, Sricharan R wrote: > Now with IOMMU probe deferral, we return -EPROBE_DEFER > for masters that are connected to an IOMMU which is not > probed yet, but going to get probed, so that we can attach > the correct dma_ops. So while trying to defer the probe of

Re: [PATCH v5 1/5] iommu: of: Fix check for returning EPROBE_DEFER

On Tue, May 23, 2017 at 06:31:29PM +0530, Sricharan R wrote: > Now with IOMMU probe deferral, we return -EPROBE_DEFER > for masters that are connected to an IOMMU which is not > probed yet, but going to get probed, so that we can attach > the correct dma_ops. So while trying to defer the probe of

Re: [PATCH v2 1/2] ACPICA: IORT: Update SMMU models for IORT rev. C

On Mon, May 22, 2017 at 04:06:37PM +0100, Robin Murphy wrote: > IORT revision C has been published with a number of new SMMU > implementation identifiers. Since IORT doesn't have any way of falling > back to a more generic model code, we really need Linux to know about > these before vendors start

Re: [PATCH v6 3/6] ACPI/IORT: Ignore all errors except EPROBE_DEFER

On Mon, May 29, 2017 at 10:36:42AM +0530, Sricharan R wrote: > Hi Rafael, > > On 5/28/2017 12:48 AM, Rafael J. Wysocki wrote: > > On Saturday, May 27, 2017 07:17:42 PM Sricharan R wrote: > >> While deferring the probe of IOMMU masters, xlate and > >> add_device callbacks called from

Device address specific mapping of arm,mmu-500

Hi All, I'm writing to check with you to see if the latest arm-smmu.c driver in v4.12-rc Linux for smmu-500 can support mapping that is only specific to a particular physical address range while leave the rest still to be handled by the client device. I believe this can already be supported by

RE: [PATCH] iommu/amd: flush IOTLB for specific domains only (v3)

>-Original Message- >From: Joerg Roedel [mailto:j...@8bytes.org] >Sent: Monday, May 29, 2017 8:09 PM >To: Nath, Arindam ; Lendacky, Thomas > >Cc: iommu@lists.linux-foundation.org; amd-...@lists.freedesktop.org; >Deucher, Alexander