From: Tirumalesh Chalamarla
This patch implements Cavium ThunderX erratum 28168.
PCI requires stores complete in order. Due to erratum #28168
PCI-inbound MSI-X store to the interrupt controller are delivered
to the interrupt controller before older PCI-inbound memory stores
are committ
Hi Robin,
On 14/11/2016 13:36, Robin Murphy wrote:
> On 04/11/16 11:24, Eric Auger wrote:
>> From: Robin Murphy
>>
>> IOMMU domain users such as VFIO face a similar problem to DMA API ops
>> with regard to mapping MSI messages in systems where the MSI write is
>> subject to IOMMU translation. Wit
On Mon, 14 Nov 2016 15:03:19 -0600
Bjorn Helgaas wrote:
> On Wed, Oct 26, 2016 at 12:01:40PM -0600, Alex Williamson wrote:
> > As described in the included code comment, this quirk is intended to
> > work around an errata in a variety of Pericom 4-lane, 3 and 4 port
> > PCIe 2.0 switches. The sw
On Wed, Oct 26, 2016 at 12:01:40PM -0600, Alex Williamson wrote:
> As described in the included code comment, this quirk is intended to
> work around an errata in a variety of Pericom 4-lane, 3 and 4 port
> PCIe 2.0 switches. The switches advertise ACS capabilities, but the
> P2P Request Redirecti
On Wed, Oct 26, 2016 at 12:01:22PM -0600, Alex Williamson wrote:
> Signed-off-by: Alex Williamson
> ---
> drivers/pci/pci.c | 26 --
> include/linux/pci.h |2 ++
> 2 files changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/p
On Wed, Oct 26, 2016 at 12:01:16PM -0600, Alex Williamson wrote:
> For use by quirks.
>
> Signed-off-by: Alex Williamson
> ---
> drivers/pci/pci.c |2 +-
> include/linux/pci.h |1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.
On Mon, Nov 14, 2016 at 12:18:44PM -0600, Tom Lendacky wrote:
> The %rsi register can be clobbered by the called function so I'm saving
> it since it points to the real mode data. I might be able to look into
> saving it earlier and restoring it before needed, but I though this
> might be clearer.
On 14/11/16 15:52, Joerg Roedel wrote:
> On Mon, Nov 14, 2016 at 12:00:47PM +, Robin Murphy wrote:
>> If we've already made the decision to move away from bus ops, I don't
>> see that it makes sense to deliberately introduce new dependencies on
>> them. Besides, as it stands, this patch literal
On 11/14/2016 11:29 AM, Borislav Petkov wrote:
> On Wed, Nov 09, 2016 at 06:35:43PM -0600, Tom Lendacky wrote:
>> This patch adds support to the early boot code to use Secure Memory
>> Encryption (SME). Support is added to update the early pagetables with
>> the memory encryption mask and to encry
On Wed, Nov 09, 2016 at 06:35:43PM -0600, Tom Lendacky wrote:
> This patch adds support to the early boot code to use Secure Memory
> Encryption (SME). Support is added to update the early pagetables with
> the memory encryption mask and to encrypt the kernel in place.
>
> The routines to set the
On 11/10/2016 4:51 AM, Borislav Petkov wrote:
> On Wed, Nov 09, 2016 at 06:34:39PM -0600, Tom Lendacky wrote:
>> This patch adds a Documenation entry to decribe the AMD Secure Memory
>> Encryption (SME) feature.
>>
>> Signed-off-by: Tom Lendacky
>> ---
>> Documentation/kernel-parameters.txt
Hi Joerg,
On 14/11/2016 17:20, Joerg Roedel wrote:
> On Mon, Nov 14, 2016 at 05:08:16PM +0100, Auger Eric wrote:
>> There are potentially several MSI doorbell physical pages in the SOC
>> that are accessed through the IOMMU (translated). Each of those must
>> have a corresponding IOVA and IOVA/PA
On 11/10/2016 07:26 PM, Kani, Toshimitsu wrote:
> On Thu, 2016-11-10 at 14:14 +0100, Borislav Petkov wrote:
>> + Toshi.
>>
>> On Wed, Nov 09, 2016 at 06:34:48PM -0600, Tom Lendacky wrote:
>>>
>>> For processors that support PAT, set the write-protect cache mode
>>> (_PAGE_CACHE_MODE_WP) entry to th
On 11/14/2016 10:32 AM, Joerg Roedel wrote:
> On Wed, Nov 09, 2016 at 06:37:32PM -0600, Tom Lendacky wrote:
>> +/* For now, disable the IOMMU if SME is active */
>> +if (sme_me_mask)
>> +return -ENODEV;
>> +
>
> Please print a message here telling the user why the IOMMU got dis
On Mon, Nov 14, 2016 at 04:52:23PM +0100, Joerg Roedel wrote:
> On Mon, Nov 14, 2016 at 12:00:47PM +, Robin Murphy wrote:
> > If we've already made the decision to move away from bus ops, I don't
> > see that it makes sense to deliberately introduce new dependencies on
> > them. Besides, as it
On Wed, Nov 09, 2016 at 06:37:32PM -0600, Tom Lendacky wrote:
> + /* For now, disable the IOMMU if SME is active */
> + if (sme_me_mask)
> + return -ENODEV;
> +
Please print a message here telling the user why the IOMMU got disabled.
Thanks,
Joerg
__
On 11/11/2016 10:17 AM, Kani, Toshimitsu wrote:
> On Wed, 2016-11-09 at 18:36 -0600, Tom Lendacky wrote:
>> Boot data (such as EFI related data) is not encrypted when the system
>> is booted and needs to be accessed unencrypted. Add support to apply
>> the proper attributes to the EFI page tables
On Mon, Nov 14, 2016 at 05:08:16PM +0100, Auger Eric wrote:
> There are potentially several MSI doorbell physical pages in the SOC
> that are accessed through the IOMMU (translated). Each of those must
> have a corresponding IOVA and IOVA/PA mapping programmed in the IOMMU.
> Else MSI will fault.
>
On Mon, Nov 14, 2016 at 11:08:05AM +0100, Marek Szyprowski wrote:
> Joerg: I hope you can merge this version on top of Greg's driver-core-next
> branch to iommu tree.
Merged Greg's driver-core-next branch and applied these on-top,
thanks Marek.
Joerg
Hi Joerg,
On 14/11/2016 16:31, Joerg Roedel wrote:
> Hi Eric,
>
> On Fri, Nov 11, 2016 at 05:45:19PM +0100, Auger Eric wrote:
>> On 11/11/2016 17:22, Joerg Roedel wrote:
>>> So I think we need a way to tell userspace about the reserved regions
>>> (per iommu-group) so that userspace knows where i
On Mon, Nov 14, 2016 at 12:16:26PM +, Robin Murphy wrote:
> With the new dma_{map,unmap}_resource() functions added to the DMA API
> for the benefit of cases like slave DMA, add suitable implementations to
> the arsenal of our generic layer. Since cache maintenance should not be
> a concern, th
On Mon, Nov 14, 2016 at 12:00:47PM +, Robin Murphy wrote:
> If we've already made the decision to move away from bus ops, I don't
> see that it makes sense to deliberately introduce new dependencies on
> them. Besides, as it stands, this patch literally implements "tell the
> iommu-core which h
Hi Eric,
On Fri, Nov 11, 2016 at 05:45:19PM +0100, Auger Eric wrote:
> On 11/11/2016 17:22, Joerg Roedel wrote:
> > So I think we need a way to tell userspace about the reserved regions
> > (per iommu-group) so that userspace knows where it can not map anything,
> Current plan is to expose that i
On Fri, Nov 11, 2016 at 09:05:43AM -0700, Alex Williamson wrote:
> On Fri, 11 Nov 2016 08:50:56 -0700
> Alex Williamson wrote:
> >
> > It's really just a happenstance that we don't map RAM over the x86 MSI
> > range though. That property really can't be guaranteed once we mix
> > architectures,
On Thu, Nov 03, 2016 at 09:04:45AM +0100, Marek Szyprowski wrote:
> This patch add support for page access protection bits. Till now this
> feature was disabled and Exynos SYSMMU always mapped pages as read/write.
> Now page access bits are set according to the protection bits provided
> in iommu_m
On Mon, Nov 14, 2016 at 12:16:26PM +, Robin Murphy wrote:
> With the new dma_{map,unmap}_resource() functions added to the DMA API
> for the benefit of cases like slave DMA, add suitable implementations to
> the arsenal of our generic layer. Since cache maintenance should not be
> a concern, th
On Fri, Nov 11, 2016 at 04:57:40PM -0600, Bjorn Helgaas wrote:
> On Thu, Nov 10, 2016 at 01:27:13PM +0100, Joerg Roedel wrote:
> > On Wed, Oct 26, 2016 at 12:01:34PM -0600, Alex Williamson wrote:
> > > Allow other parts of the kernel to see which PCI ACS flags the IOMMU
> > > layer considers necess
On 04/11/16 11:24, Eric Auger wrote:
> From: Robin Murphy
>
> IOMMU domain users such as VFIO face a similar problem to DMA API ops
> with regard to mapping MSI messages in systems where the MSI write is
> subject to IOMMU translation. With the relevant infrastructure now in
> place for managed D
With the new dma_{map,unmap}_resource() functions added to the DMA API
for the benefit of cases like slave DMA, add suitable implementations to
the arsenal of our generic layer. Since cache maintenance should not be
a concern, these can both be standalone callback implementations without
the need f
With no coherency to worry about, just plug'em straight in.
Acked-by: Catalin Marinas
Signed-off-by: Robin Murphy
---
arch/arm64/mm/dma-mapping.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 3f74d0d98de6..5cd0a383b14b 1006
On 14/11/16 10:26, Lorenzo Pieralisi wrote:
> Hi Robin, Joerg,
>
> On Fri, Nov 11, 2016 at 05:43:39PM +, Robin Murphy wrote:
>> On 11/11/16 16:27, Joerg Roedel wrote:
>>> On Fri, Nov 11, 2016 at 04:17:37PM +, Robin Murphy wrote:
In the original of_iommu_configure design, the thought w
Hello Ashok Raj,
This is a semi-automatic email about new static checker warnings.
The patch 1c387188c60f: "iommu/vt-d: Fix IOMMU lookup for SR-IOV
Virtual Functions" from Oct 21, 2016, leads to the following Smatch
complaint:
drivers/iommu/intel-iommu.c:918 device_to_iommu()
error: w
Hi Robin, Joerg,
On Fri, Nov 11, 2016 at 05:43:39PM +, Robin Murphy wrote:
> On 11/11/16 16:27, Joerg Roedel wrote:
> > On Fri, Nov 11, 2016 at 04:17:37PM +, Robin Murphy wrote:
> >> In the original of_iommu_configure design, the thought was that an ops
> >> structure could be IOMMU-instan
This patch adds runtime pm implementation, which is based on previous
suspend/resume code. SYSMMU controller is now being enabled/disabled mainly
from the runtime pm callbacks. System sleep callbacks relies on generic
pm_runtime_force_suspend/pm_runtime_force_resume helpers. To ensure
internal stat
This patch uses recently introduced device dependency links to track the
runtime pm state of the master's device. The goal is to let SYSMMU
controller device's runtime PM to follow the runtime PM state of the
respective master's device. This way each SYSMMU controller is active
only when its master
Remove remaining leftovers of the ref-count related code in the
__sysmmu_enable/disable functions inline __sysmmu_enable/disable_nocount
to them. Suspend/resume callbacks now checks if master device is set for
given SYSMMU controller instead of relying on the activation count.
Signed-off-by: Marek
To avoid possible races, set master device pointer in each SYSMMU
controller once on boot. Suspend/resume callbacks now properly relies on
the configured iommu domain to enable or disable SYSMMU controller.
While changing the code, also update the sleep debug messages and make
them conditional.
Si
__sysmmu_enable/disable functions were designed to do ref-count based
operations, but current code always calls them only once, so the code for
checking the conditions and invalid conditions can be simply removed
without any influence to the driver operation.
Signed-off-by: Marek Szyprowski
---
This patch reworks locking in the exynos_iommu_attach/detach_device
functions to ensure that all entries of the sysmmu_drvdata and
exynos_iommu_owner structure are updated under the respective spinlocks,
while runtime pm functions are called without any spinlocks held.
Signed-off-by: Marek Szyprow
Remove excessive, useless debug about skipping TLB invalidation, which
is a normal situation when more aggressive power management is enabled.
Signed-off-by: Marek Szyprowski
---
drivers/iommu/exynos-iommu.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/iommu/exynos-iommu.c b/dri
Hello,
This is another update of the patchset for adding proper runtime PM
support to Exynos IOMMU driver. This has been achieved by using recently
introduced device links, which lets SYSMMU controller's runtime PM to
follow master's device runtime PM state (the device which actually
performs DMA
41 matches
Mail list logo
