On Fri, Jan 18, 2019 at 12:17:05PM +, Eric Wong wrote:
> @@ -5411,6 +5411,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20,
> quirk_iommu_g4x_gfx);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_g4x_gfx);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40,
Hi Suravee,
On Thu, Jan 17, 2019 at 08:44:36AM +, Suthikulpanit, Suravee wrote:
> Then, in __domain_flush_pages, we issue command when the dev_iommu[] >= 0.
> This should preserve previous behavior, and only add flushing condition to
> the specific IOMMU in detached state. Please let me know
On Tue, Jan 22, 2019 at 11:39 AM Joerg Roedel wrote:
>
> On Fri, Jan 18, 2019 at 12:17:05PM +, Eric Wong wrote:
> > @@ -5411,6 +5411,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20,
> > quirk_iommu_g4x_gfx);
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30,
Hi Daniel,
On Tue, Jan 22, 2019 at 11:46:39AM +0100, Daniel Vetter wrote:
> Note that the string of platforms which have various issues with iommu
> and igfx is very long, thus far we only disabled it where there's no
> workaround to stop it from hanging the box, but otherwise left it
> enabled.
On Thu, Jan 17, 2019 at 12:29:02PM -0700, Jerry Snitselaar wrote:
> In the error path of map_sg, free_iova_fast is being called with
> address instead of the pfn. This results in a bad value getting into
> the rcache, and can result in hitting a BUG_ON when
> iova_magazine_free_pfns is called.
>
On Wed, Jan 16, 2019 at 08:11:44PM +0100, Gerald Schaefer wrote:
> Commit 9d3a4de4cb8d ("iommu: Disambiguate MSI region types") changed
> the reserved region type in intel_iommu_get_resv_regions() from
> IOMMU_RESV_RESERVED to IOMMU_RESV_MSI, but it forgot to also change
> the type in
On Fri, Jan 18, 2019 at 12:35:43PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 16, 2019 at 06:10:13PM +, Robin Murphy wrote:
> > It's a shame that this is pretty much a duplication of
> > debug_dma_dump_mappings(), but there seems no straightforward way to define
> > one in terms of the
Hi Andrew,
On Fri, Jan 11, 2019 at 6:21 PM Joerg Roedel wrote:
>
> On Wed, Jan 02, 2019 at 01:51:45PM +0800, Nicolas Boichat wrote:
> > Does anyone have any further comment on this series? If not, which
> > maintainer is going to pick this up? I assume Andrew Morton?
>
> Probably, yes. I don't
Hi,
thanks for quick reply, this seems to fix it
no crash, xserver works, like revert of the commit...pushed the fix to below
github-repo
regards Frank
> Gesendet: Dienstag, 22. Januar 2019 um 17:49 Uhr
> Von: "Joerg Roedel"
> An: "Frank Wunderlich"
> Cc: "Matthias Brugger" ,
>
On Mon, Jan 21, 2019 at 03:56:29PM -0800, Stefano Stabellini wrote:
> > Where should we pick this up? I could pick it up through the dma-mapping
> > tree given that is where the problem is introduced, but the Xen or arm64
> > trees would also fit.
>
> I am happy for you to carry it in the
Currently the Intel IOMMU uses the default dma_[un]map_resource()
implementations does nothing and simply returns the physical address
unmodified.
However, this doesn't create the IOVA entries necessary for addresses
mapped this way to work when the IOMMU is enabled. Thus, when the
IOMMU is
Lendacky, Thomas writes:
> On 1/22/19 3:17 PM, Thiago Jung Bauermann wrote:
>> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
>> index 355d16acee6d..bc78c37220ba 100644
>> --- a/kernel/dma/direct.c
>> +++ b/kernel/dma/direct.c
>> @@ -166,7 +166,7 @@ void *dma_direct_alloc_pages(struct
On 1/22/19 3:17 PM, Thiago Jung Bauermann wrote:
> From: Ram Pai
>
> set_memory_encrypted() and set_memory_decrypted() expect the number of
> PAGE_SIZE pages to encrypt or decrypt. dma_direct_alloc() and
> dma_direct_free() instead pass number of bytes. This encrypts/decrypts a
> huge number of
From: Ram Pai
set_memory_decrypted() expects the number of PAGE_SIZE pages to decrypt.
kvmclock_init_mem() instead passes number of bytes. This decrypts a huge
number of pages resulting in data corruption.
Fixed it.
[ bauermann: Slightly reworded commit message and added Fixes: tag. ]
Fixes:
From: Ram Pai
set_memory_encrypted() and set_memory_decrypted() expect the number of
PAGE_SIZE pages to encrypt or decrypt. dma_direct_alloc() and
dma_direct_free() instead pass number of bytes. This encrypts/decrypts a
huge number of pages resulting in data corruption.
Fixed it.
[ bauermann:
On 1/22/19 3:17 PM, Thiago Jung Bauermann wrote:
> From: Ram Pai
>
> set_memory_decrypted() expects the number of PAGE_SIZE pages to decrypt.
> kvmclock_init_mem() instead passes number of bytes. This decrypts a huge
> number of pages resulting in data corruption.
Same comment as patch 1/2 in
Hi Suravee,
On Tue, Jan 22, 2019 at 03:53:18PM +, Suthikulpanit, Suravee wrote:
> Thanks for the detail. Alright then, let's just go with the version you
> sent on 1/16/19. Do you want me to resend V3 with that changes, or
> would you be taking care of that?
Please send me a v3 based on the
From: Joerg Roedel
The mtk_iommu_add_device() function keeps the fwspec in an
on-stack pointer and calls mtk_iommu_create_mapping(), which
might change its source, dev->iommu_fwspec. This causes the
on-stack pointer to be obsoleted and the device
initialization to fail. Update the on-stack
Quoting Joerg Roedel (2019-01-22 13:01:09)
> Hi Daniel,
>
> On Tue, Jan 22, 2019 at 11:46:39AM +0100, Daniel Vetter wrote:
> > Note that the string of platforms which have various issues with iommu
> > and igfx is very long, thus far we only disabled it where there's no
> > workaround to stop it
Hi Frank,
thanks for the report!
On Tue, Jan 22, 2019 at 05:09:09PM +0100, Frank Wunderlich wrote:
> Hi,
>
> the following Patch breaks hdmi (at least) on Bananapi R2 (mt7623):
>
> a9bf2eec5a6fc01a0a5250eaf0bf61dfd382a78a "iommu/mediatek: Use helper
> functions to access dev->iommu_fwspec"
On Tue, Jan 22, 2019 at 06:44:38PM +, Robin Murphy wrote:
> Hi Greg,
>
> On 22/01/2019 15:21, Greg Kroah-Hartman wrote:
> > When calling debugfs functions, there is no need to ever check the
> > return value. The function can work or not, but the code logic should
> > never do something
On Mon, Jan 21, 2019 at 7:23 PM Robin Murphy wrote:
>
> On 21/01/2019 05:53, Vivek Gautam wrote:
> > A number of arm_smmu_domain's attributes can be assigned based
> > on the iommu domains's attributes. These local attributes better
> > be managed by a bitmap.
> > So remove boolean flags and move
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Also delete the variables for the file dentries for the debugfs entries
as they are never used at all once they are
Joerg,
On 1/22/19 5:44 PM, j...@8bytes.org wrote:
> Hi Suravee,
>
> On Thu, Jan 17, 2019 at 08:44:36AM +, Suthikulpanit, Suravee wrote:
>> Then, in __domain_flush_pages, we issue command when the dev_iommu[] >= 0.
>> This should preserve previous behavior, and only add flushing condition to
On Mon, 21 Jan 2019 12:51:14 +0100
Pierre Morel wrote:
> On 18/01/2019 14:51, Jean-Philippe Brucker wrote:
> > Hi Pierre,
> >
> > On 18/01/2019 13:29, Pierre Morel wrote:
> >> On 17/01/2019 14:02, Robin Murphy wrote:
> >>> On 15/01/2019 17:37, Pierre Morel wrote:
> The s390 iommu can
On Tue, Jan 22, 2019 at 04:48:26PM +0200, Joonas Lahtinen wrote:
> According to our IOMMU folks there exists some desire to be able to assign
> the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off
> due to how the devices might be grouped in IOMMU groups. Even when you
> would
Hi Greg,
On 22/01/2019 15:21, Greg Kroah-Hartman wrote:
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Also delete the variables for the file dentries for the
Hi,
the following Patch breaks hdmi (at least) on Bananapi R2 (mt7623):
a9bf2eec5a6fc01a0a5250eaf0bf61dfd382a78a "iommu/mediatek: Use helper functions
to access dev->iommu_fwspec"
28 matches
Mail list logo
