On Thu, 2016-11-17 at 15:35 -0800, Stephen Boyd wrote:
> On 11/17, Honghui Zhang wrote:
> > On Wed, 2016-11-16 at 11:38 -0800, Stephen Boyd wrote:
> > > On 11/16, Arnd Bergmann wrote:
> > > > After the MT2701 clock driver was added, we get a harmless warning for
> > > > the iommu driver that
On 11/17, Honghui Zhang wrote:
> On Wed, 2016-11-16 at 11:38 -0800, Stephen Boyd wrote:
> > On 11/16, Arnd Bergmann wrote:
> > > After the MT2701 clock driver was added, we get a harmless warning for
> > > the iommu driver that selects it, when compile-testing without
> > > COMMON_CLK.
> > >
> >
On 11/17/2016 04:41 PM, Joerg Roedel wrote:
Hi Mark,
On Thu, Nov 17, 2016 at 02:13:59PM -0500, Mark Hounschell wrote:
Kernel version is 4.8.0. No failure when the IOMMU is disabled. This
is an out of tree GPL driver using
pci_alloc_consistent/pci_free_consistent. The free causes this.
Can
On Thu, Nov 17, 2016 at 04:53:24PM -0500, Mark Hounschell wrote:
> On 11/17/2016 04:41 PM, Joerg Roedel wrote:
> >Hi Mark,
> >
> >On Thu, Nov 17, 2016 at 02:13:59PM -0500, Mark Hounschell wrote:
> >>Kernel version is 4.8.0. No failure when the IOMMU is disabled. This
> >>is an out of tree GPL
Hi Mark,
On Thu, Nov 17, 2016 at 02:13:59PM -0500, Mark Hounschell wrote:
> Kernel version is 4.8.0. No failure when the IOMMU is disabled. This
> is an out of tree GPL driver using
> pci_alloc_consistent/pci_free_consistent. The free causes this.
Can you please run the driver with dma-api
Kernel version is 4.8.0. No failure when the IOMMU is disabled. This is an out
of tree GPL driver using pci_alloc_consistent/pci_free_consistent. The free
causes this.
The commit is:
2d4c515bf06c9bce87b546279413621f847ef6a3 is the first bad commit
commit
On Wed, Nov 09, 2016 at 06:37:08PM -0600, Tom Lendacky wrote:
> When Secure Memory Encryption is enabled, the trampoline area must not
> be encrypted. A CPU running in real mode will not be able to decrypt
> memory that has been encrypted because it will not be able to use addresses
> with the
tree: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next
head: e74ee64c77fb60776247b9f8f5e478117c32cd0f
commit: e74ee64c77fb60776247b9f8f5e478117c32cd0f [1/1] Merge branches
'arm/mediatek', 'x86/amd', 'core' and 'arm/exynos' into next
config: x86_64-randconfig-i0-201646
On Wed, Nov 09, 2016 at 06:36:55PM -0600, Tom Lendacky wrote:
> This patch adds support to be change the memory encryption attribute for
> one or more memory pages.
"Add support for changing ..."
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/cacheflush.h
tree: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next
head: e74ee64c77fb60776247b9f8f5e478117c32cd0f
commit: e74ee64c77fb60776247b9f8f5e478117c32cd0f [1/1] Merge branches
'arm/mediatek', 'x86/amd', 'core' and 'arm/exynos' into next
config: i386-randconfig-a0-201646
On Wed, Nov 09, 2016 at 06:36:31PM -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 and to the early_memremap and
> memremap APIs
On Wed, Nov 09, 2016 at 06:36:20PM -0600, Tom Lendacky wrote:
> The boot data and command line data are present in memory in an
> un-encrypted state and are copied early in the boot process. The early
> page fault support will map these areas as encrypted, so before attempting
> to copy them, add
Hi Sricharan,
On 2016-11-17 12:20, Sricharan R wrote:
arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops()
,dma_ops should be cleared in the teardown path. Otherwise
this causes problem when the probe of device is retried after
being deferred. The device's iommu structures are
arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops()
,dma_ops should be cleared in the teardown path. Otherwise
this causes problem when the probe of device is retried after
being deferred. The device's iommu structures are cleared
after EPROBEDEFER error, but on the next try dma_ops
14 matches
Mail list logo