On Tue, Nov 06, 2018 at 11:54:15AM +, Robin Murphy wrote:
> of_dma_configure() was *supposed* to be following the same logic as
> acpi_dma_configure() and only setting bus_dma_mask if some range was
> specified by the firmware. However, it seems that subtlety got lost in
> the process of fittin
Hi Robin,
On Tue, Nov 6, 2018 at 12:54 PM Robin Murphy wrote:
> of_dma_configure() was *supposed* to be following the same logic as
> acpi_dma_configure() and only setting bus_dma_mask if some range was
> specified by the firmware. However, it seems that subtlety got lost in
> the process of fitt
Hi Robin,
On Tue, Nov 6, 2018 at 9:20 PM Robin Murphy wrote:
> On 2018-11-06 7:44 pm, Geert Uytterhoeven wrote:
> > On Tue, Oct 23, 2018 at 1:40 AM Linux Kernel Mailing List
> > wrote:
> >> Commit: b4ebe6063204da58e48600b810a97c29ae9e5d12
> >> Parent: 7d21ee4c719f00896767ce19c4c01a56374c
On 06.11.18 11:54:15, Robin Murphy wrote:
> of_dma_configure() was *supposed* to be following the same logic as
> acpi_dma_configure() and only setting bus_dma_mask if some range was
> specified by the firmware. However, it seems that subtlety got lost in
> the process of fitting it into the differ
On 07.11.18 11:31:50, Robert Richter wrote:
> On 06.11.18 11:54:15, Robin Murphy wrote:
> > of_dma_configure() was *supposed* to be following the same logic as
> > acpi_dma_configure() and only setting bus_dma_mask if some range was
> > specified by the firmware. However, it seems that subtlety got
On 2018-11-07 12:08 pm, Richter, Robert wrote:
On 07.11.18 11:31:50, Robert Richter wrote:
On 06.11.18 11:54:15, Robin Murphy wrote:
of_dma_configure() was *supposed* to be following the same logic as
acpi_dma_configure() and only setting bus_dma_mask if some range was
specified by the firmware
On 2018-11-07 8:03 am, Christoph Hellwig wrote:
On Tue, Nov 06, 2018 at 11:54:15AM +, Robin Murphy wrote:
of_dma_configure() was *supposed* to be following the same logic as
acpi_dma_configure() and only setting bus_dma_mask if some range was
specified by the firmware. However, it seems that
If iommu_ops.add_device() fails, iommu_ops.domain_free() is still
called, leading to a crash, as the domain was only partially
initialized:
ipmmu-vmsa e67b.mmu: Cannot accommodate DMA translation for IOMMU page
tables
sata_rcar ee30.sata: Unable to initialize IPMMU context
iom
On 2018-11-07 1:18 pm, Geert Uytterhoeven wrote:
If iommu_ops.add_device() fails, iommu_ops.domain_free() is still
called, leading to a crash, as the domain was only partially
initialized:
ipmmu-vmsa e67b.mmu: Cannot accommodate DMA translation for IOMMU page
tables
sata_rcar ee30
On Wed, Nov 07, 2018 at 01:22:52PM +, Robin Murphy wrote:
> On 2018-11-07 1:18 pm, Geert Uytterhoeven wrote:
> > Fix this by checking if the domain's context already exists, before
> > trying to destroy it.
>
> Reviewed-by: Robin Murphy
Does this need a Fixes-tag? If so, which patch should b
Hi Jörg,
On Wed, Nov 7, 2018 at 4:34 PM Joerg Roedel wrote:
> On Wed, Nov 07, 2018 at 01:22:52PM +, Robin Murphy wrote:
> > On 2018-11-07 1:18 pm, Geert Uytterhoeven wrote:
> > > Fix this by checking if the domain's context already exists, before
> > > trying to destroy it.
> >
> > Reviewed-b
On Wed, Nov 07, 2018 at 12:56:49PM +, Robin Murphy wrote:
> On 2018-11-07 8:03 am, Christoph Hellwig wrote:
> > On Tue, Nov 06, 2018 at 11:54:15AM +, Robin Murphy wrote:
> > > of_dma_configure() was *supposed* to be following the same logic as
> > > acpi_dma_configure() and only setting bus
On Wed, Nov 07, 2018 at 04:50:40PM +0100, Geert Uytterhoeven wrote:
> It only got triggered by the combination of commits 6c2fb2ea76361da9
> ("of/device: Set bus DMA mask as appropriate") and b4ebe6063204da58
> ("dma-direct: implement complete bus_dma_mask handling"), which is being
> fixed by "of/
On Wed, Nov 07, 2018 at 02:18:50PM +0100, Geert Uytterhoeven wrote:
> Fix this by checking if the domain's context already exists, before
> trying to destroy it.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/iommu/ipmmu-vmsa.c | 3 +++
> 1 file changed, 3 insertions(+)
Applied, thanks
On Tue, Nov 06, 2018 at 02:47:15PM -0800, Jacob Pan wrote:
> drivers/iommu/intel-iommu.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.
On 2018-11-07 4:03 pm, Joerg Roedel wrote:
On Wed, Nov 07, 2018 at 04:50:40PM +0100, Geert Uytterhoeven wrote:
It only got triggered by the combination of commits 6c2fb2ea76361da9
("of/device: Set bus DMA mask as appropriate") and b4ebe6063204da58
("dma-direct: implement complete bus_dma_mask ha
On 2018-11-07 3:52 pm, Rob Herring wrote:
On Wed, Nov 07, 2018 at 12:56:49PM +, Robin Murphy wrote:
On 2018-11-07 8:03 am, Christoph Hellwig wrote:
On Tue, Nov 06, 2018 at 11:54:15AM +, Robin Murphy wrote:
of_dma_configure() was *supposed* to be following the same logic as
acpi_dma_con
of_dma_configure() was *supposed* to be following the same logic as
acpi_dma_configure() and only setting bus_dma_mask if some range was
specified by the firmware. However, it seems that subtlety got lost in
the process of fitting it into the differently-shaped control flow, and
as a result the for
Hi,
On Wed, Nov 07, 2018 at 11:40:30AM +0800, Lu Baolu wrote:
> Hi Joerg,
>
> On 11/7/18 12:25 AM, j...@8bytes.org wrote:
> Nowadays, we can find PASID granular DMA translation on both ARM and x86
> platforms. With PASID granular DMA translation supported in system iommu, if
> a device divides it
On Wed, Nov 07, 2018 at 04:17:09PM +, Robin Murphy wrote:
> FWIW it looks like it *has* always been possible to hit this crash by
> allocating a domain and freeing it again without attaching any devices, it's
> just highly improbable for any sane code to do that explicitly, so the real
> latent
On Wed, 7 Nov 2018 17:43:23 +0100
"j...@8bytes.org" wrote:
> Hi,
>
> On Wed, Nov 07, 2018 at 11:40:30AM +0800, Lu Baolu wrote:
> > Hi Joerg,
> >
> > On 11/7/18 12:25 AM, j...@8bytes.org wrote:
> > Nowadays, we can find PASID granular DMA translation on both ARM and x86
> > platforms. With PASID
Hey,
> On 7 Nov 2018, at 02:10, Lu Baolu wrote:
>
> Hi,
>
> On 11/6/18 6:40 PM, James Sewart wrote:
>> Hey Lu,
>> Would you be able to go into more detail about the issues with
>> allowing IOMMU_DOMAIN_DMA to be allocated via domain_alloc?
>
> This door is closed because intel iommu driver doe
On Wed, Nov 07, 2018 at 04:30:32PM +, Robin Murphy wrote:
> of_dma_configure() was *supposed* to be following the same logic as
> acpi_dma_configure() and only setting bus_dma_mask if some range was
> specified by the firmware. However, it seems that subtlety got lost in
> the process of fittin
On Wed, 7 Nov 2018 17:04:28 +0100
Joerg Roedel wrote:
> On Tue, Nov 06, 2018 at 02:47:15PM -0800, Jacob Pan wrote:
> > drivers/iommu/intel-iommu.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
>
> Applied, thanks.
Hi Joerg,
We have found some issues with this patch on some p
Hi,
On 11/8/18 1:55 AM, James Sewart wrote:
Hey,
On 7 Nov 2018, at 02:10, Lu Baolu wrote:
Hi,
On 11/6/18 6:40 PM, James Sewart wrote:
Hey Lu,
Would you be able to go into more detail about the issues with
allowing IOMMU_DOMAIN_DMA to be allocated via domain_alloc?
This door is closed bec
Hi Yi,
On 11/7/18 2:07 PM, Liu, Yi L wrote:
Hi Baolu,
From: Lu Baolu [mailto:baolu...@linux.intel.com]
Sent: Monday, November 5, 2018 1:32 PM
[...]
---
drivers/iommu/dmar.c| 83 +++--
drivers/iommu/intel-svm.c | 76 --
Hi,
On 11/7/18 2:55 PM, Liu, Yi L wrote:
Hi Baolu,
From: Lu Baolu [mailto:baolu...@linux.intel.com]
Sent: Monday, November 5, 2018 1:32 PM
Subject: [PATCH v4 05/12] iommu/vt-d: Reserve a domain id for FL and PT modes
Vt-d spec rev3.0 (section 6.2.3.1) requires that each pasid
entry for first-
Hi,
On 11/7/18 3:13 PM, Liu, Yi L wrote:
Hi Baolu,
From: Lu Baolu [mailto:baolu...@linux.intel.com]
Sent: Monday, November 5, 2018 1:32 PM
This adds the interfaces to setup or tear down the structures
for second level page table translations. This includes types
of second level only translati
Hi,
On 11/7/18 3:25 PM, Liu, Yi L wrote:
Hi Baolu,
From: Lu Baolu [mailto:baolu...@linux.intel.com]
Sent: Monday, November 5, 2018 1:32 PM
Subject: [PATCH v4 08/12] iommu/vt-d: Pass pasid table to context mapping
So that the pasid related info, such as the pasid table and the
maximum of pasid
Hi,
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Thursday, November 8, 2018 10:17 AM
> Subject: Re: [PATCH v4 04/12] iommu/vt-d: Add 256-bit invalidation descriptor
> support
>
> Hi Yi,
>
> On 11/7/18 2:07 PM, Liu, Yi L wrote:
> > Hi Baolu,
> >
> >> From: Lu Baolu [mailto:baolu...@
Hi,
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Thursday, November 8, 2018 10:28 AM
> Subject: Re: [PATCH v4 06/12] iommu/vt-d: Add second level page table
> interface
>
> Hi,
>
> On 11/7/18 3:13 PM, Liu, Yi L wrote:
> > Hi Baolu,
> >
> >> From: Lu Baolu [mailto:baolu...@linux.in
Hi,
On 11/8/18 11:49 AM, Liu, Yi L wrote:
Hi,
From: Lu Baolu [mailto:baolu...@linux.intel.com]
Sent: Thursday, November 8, 2018 10:17 AM
Subject: Re: [PATCH v4 04/12] iommu/vt-d: Add 256-bit invalidation descriptor
support
Hi Yi,
On 11/7/18 2:07 PM, Liu, Yi L wrote:
Hi Baolu,
From: Lu Bao
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Thursday, November 8, 2018 1:25 PM
> Subject: Re: [PATCH v4 04/12] iommu/vt-d: Add 256-bit invalidation descriptor
> support
>
> Hi,
>
> On 11/8/18 11:49 AM, Liu, Yi L wrote:
> > Hi,
> >
> >> From: Lu Baolu [mailto:baolu...@linux.intel.c
> From: Liu, Yi L
> Sent: Thursday, November 8, 2018 1:45 PM
> > + memcpy(desc, qi->desc + (wait_index << shift),
> > >>>
> > >>> Would "memcpy(desc, (unsigned long long) (qi->desc + (wait_index
> > >>> << shift)," be more safe?
> > >>
> > >> Can that be compiled? memcpy(
From: Yue Haibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/iommu/amd_iommu.c: In function 'iommu_print_event':
drivers/iommu/amd_iommu.c:550:33: warning:
variable 'tag' set but not used [-Wunused-but-set-variable]
It never used since introduction in
commit e7f63ffc1bf1 ("iommu/am
Hi,
On 11/8/18 1:45 PM, Liu, Yi L wrote:
From: Lu Baolu [mailto:baolu...@linux.intel.com]
Sent: Thursday, November 8, 2018 1:25 PM
Subject: Re: [PATCH v4 04/12] iommu/vt-d: Add 256-bit invalidation descriptor
support
Hi,
On 11/8/18 11:49 AM, Liu, Yi L wrote:
Hi,
From: Lu Baolu [mailto:baolu
On 11/8/18 1:48 PM, Liu, Yi L wrote:
From: Liu, Yi L
Sent: Thursday, November 8, 2018 1:45 PM
+ memcpy(desc, qi->desc + (wait_index << shift),
Would "memcpy(desc, (unsigned long long) (qi->desc + (wait_index
<< shift)," be more safe?
Can that be compiled? memcpy() re
Hi,
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Thursday, November 8, 2018 2:14 PM
>
> Hi,
>
> On 11/8/18 1:45 PM, Liu, Yi L wrote:
> >> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> >> Sent: Thursday, November 8, 2018 1:25 PM
> >> Subject: Re: [PATCH v4 04/12] iommu/vt-d: Ad
Hi Robin,
After the commit ad67f5a6545f ("arm64: replace ZONE_DMA with
ZONE_DMA32"), we don't have ZONE_DMA in aarch64, but
__arm_v7s_alloc_table[1] use the GFP_DMA to expect the physical address
of pagetable should be 32bit.
Right now we meet a issue that the lvl1 pagetable PA is 0x1_3ab6_ i
39 matches
Mail list logo
