All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
To: Jon Nettleton <jon@solid-run.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Laurentiu Tudor <laurentiu.tudor@nxp.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"ACPI Devel Maling List" <linux-acpi@vger.kernel.org>,
	Linux IOMMU <iommu@lists.linux-foundation.org>,
	Joerg Roedel <joro@8bytes.org>, "Will Deacon" <will@kernel.org>,
	wanghuiqiang <wanghuiqiang@huawei.com>,
	"Guohanjun (Hanjun Guo)" <guohanjun@huawei.com>,
	Steven Price <steven.price@arm.com>,
	Sami Mujawar <Sami.Mujawar@arm.com>,
	Eric Auger <eric.auger@redhat.com>,
	yangyicong <yangyicong@huawei.com>
Subject: RE: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing
Date: Thu, 16 Sep 2021 08:26:14 +0000	[thread overview]
Message-ID: <e02a00a10ea3440dab1f9f9320de42ad@huawei.com> (raw)
In-Reply-To: <CABdtJHuEViN0MSz-ZJhR52+b=F6yvQ5mm_edVuLy1B=nHp+ESQ@mail.gmail.com>



> -----Original Message-----
> From: Jon Nettleton [mailto:jon@solid-run.com]
> Sent: 16 September 2021 08:52
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: Robin Murphy <robin.murphy@arm.com>; Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com>; Laurentiu Tudor <laurentiu.tudor@nxp.com>;
> linux-arm-kernel <linux-arm-kernel@lists.infradead.org>; ACPI Devel Maling
> List <linux-acpi@vger.kernel.org>; Linux IOMMU
> <iommu@lists.linux-foundation.org>; Joerg Roedel <joro@8bytes.org>; Will
> Deacon <will@kernel.org>; wanghuiqiang <wanghuiqiang@huawei.com>;
> Guohanjun (Hanjun Guo) <guohanjun@huawei.com>; Steven Price
> <steven.price@arm.com>; Sami Mujawar <Sami.Mujawar@arm.com>; Eric
> Auger <eric.auger@redhat.com>; yangyicong <yangyicong@huawei.com>
> Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing
> 
> On Thu, Sep 16, 2021 at 9:26 AM Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Jon Nettleton [mailto:jon@solid-run.com]
> > > Sent: 06 September 2021 20:51
> > > To: Robin Murphy <robin.murphy@arm.com>
> > > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>; Shameerali
> > > Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>; Laurentiu
> > > Tudor <laurentiu.tudor@nxp.com>; linux-arm-kernel
> > > <linux-arm-kernel@lists.infradead.org>; ACPI Devel Maling List
> > > <linux-acpi@vger.kernel.org>; Linux IOMMU
> > > <iommu@lists.linux-foundation.org>; Linuxarm <linuxarm@huawei.com>;
> > > Joerg Roedel <joro@8bytes.org>; Will Deacon <will@kernel.org>;
> > > wanghuiqiang <wanghuiqiang@huawei.com>; Guohanjun (Hanjun Guo)
> > > <guohanjun@huawei.com>; Steven Price <steven.price@arm.com>; Sami
> > > Mujawar <Sami.Mujawar@arm.com>; Eric Auger
> <eric.auger@redhat.com>;
> > > yangyicong <yangyicong@huawei.com>
> > > Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node
> > > parsing
> > >
> > [...]
> >
> > > > >
> > > > > On the prot value assignment based on the remapping flag, I'd
> > > > > like to hear Robin/Joerg's opinion, I'd avoid being in a
> > > > > situation where "normally" this would work but then we have to quirk
> it.
> > > > >
> > > > > Is this a valid assumption _always_ ?
> > > >
> > > > No. Certainly applying IOMMU_CACHE without reference to the
> > > > device's _CCA attribute or how CPUs may be accessing a shared
> > > > buffer could lead to a loss of coherency. At worst, applying
> > > > IOMMU_MMIO to a device-private buffer *could* cause the device to
> > > > lose coherency with itself if the memory underlying the RMR may
> > > > have allocated into system caches. Note that the expected use for
> > > > non-remappable RMRs is the device holding some sort of long-lived
> > > > private data in system RAM - the MSI doorbell trick is far more of a niche
> hack really.
> > > >
> > > > At the very least I think we need to refer to the device's memory
> > > > access properties here.
> > > >
> > > > Jon, Laurentiu - how do RMRs correspond to the EFI memory map on
> > > > your firmware? I'm starting to think that as long as the
> > > > underlying memory is described appropriately there then we should
> > > > be able to infer correct attributes from the EFI memory type and flags.
> > >
> > > The devices are all cache coherent and marked as _CCA, 1.  The
> > > Memory regions are in the virt table as
> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE.
> > >
> > > The current chicken and egg problem we have is that during the
> > > fsl-mc-bus initialization we call
> > >
> > > error = acpi_dma_configure_id(&pdev->dev, DEV_DMA_COHERENT,
> > >                                               &mc_stream_id);
> > >
> > > which gets deferred because the SMMU has not been initialized yet.
> > > Then we initialize the RMR tables but there is no device reference
> > > there to be able to query device properties, only the stream id.
> > > After the IORT tables are parsed and the SMMU is setup, on the
> > > second device probe we associate everything based on the stream id
> > > and the fsl-mc-bus device is able to claim its 1-1 DMA mappings.
> >
> > Can we solve this order problem by delaying the
> > iommu_alloc_resv_region() to the iommu_dma_get_rmr_resv_regions(dev,
> > list) ? We could invoke
> > device_get_dma_attr() from there which I believe will return the _CCA
> attribute.
> >
> > Or is that still early to invoke that?
> 
> That looks like it should work. Do we then also need to parse through the
> VirtualMemoryTable matching the start and end addresses to determine the
> other memory attributes like MMIO?

Yes. But that looks tricky as I can't find that readily available on Arm, like the
efi_mem_attributes(). I will take a look.

Please let me know if there is one or any other easy way to retrieve it.

Thanks,
Shameer

> 
> -Jon
> 
> >
> > Thanks,
> > Shameer
> >
> > > cat /sys/kernel/iommu_groups/0/reserved_regions
> > > 0x0000000001000000 0x0000000010ffffff direct-relaxable
> > > 0x0000000008000000 0x00000000080fffff msi
> > > 0x000000080c000000 0x000000081bffffff direct-relaxable
> > > 0x0000001c00000000 0x0000001c001fffff direct-relaxable
> > > 0x0000002080000000 0x000000209fffffff direct-relaxable
> > >
> > > -Jon
> > >
> > > >
> > > > Robin.

WARNING: multiple messages have this Message-ID (diff)
From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
To: Jon Nettleton <jon@solid-run.com>
Cc: Will Deacon <will@kernel.org>,
	Steven Price <steven.price@arm.com>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linux IOMMU <iommu@lists.linux-foundation.org>,
	wanghuiqiang <wanghuiqiang@huawei.com>,
	"Guohanjun \(Hanjun Guo\)" <guohanjun@huawei.com>,
	yangyicong <yangyicong@huawei.com>,
	Sami Mujawar <Sami.Mujawar@arm.com>,
	Robin Murphy <robin.murphy@arm.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing
Date: Thu, 16 Sep 2021 08:26:14 +0000	[thread overview]
Message-ID: <e02a00a10ea3440dab1f9f9320de42ad@huawei.com> (raw)
In-Reply-To: <CABdtJHuEViN0MSz-ZJhR52+b=F6yvQ5mm_edVuLy1B=nHp+ESQ@mail.gmail.com>



> -----Original Message-----
> From: Jon Nettleton [mailto:jon@solid-run.com]
> Sent: 16 September 2021 08:52
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: Robin Murphy <robin.murphy@arm.com>; Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com>; Laurentiu Tudor <laurentiu.tudor@nxp.com>;
> linux-arm-kernel <linux-arm-kernel@lists.infradead.org>; ACPI Devel Maling
> List <linux-acpi@vger.kernel.org>; Linux IOMMU
> <iommu@lists.linux-foundation.org>; Joerg Roedel <joro@8bytes.org>; Will
> Deacon <will@kernel.org>; wanghuiqiang <wanghuiqiang@huawei.com>;
> Guohanjun (Hanjun Guo) <guohanjun@huawei.com>; Steven Price
> <steven.price@arm.com>; Sami Mujawar <Sami.Mujawar@arm.com>; Eric
> Auger <eric.auger@redhat.com>; yangyicong <yangyicong@huawei.com>
> Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing
> 
> On Thu, Sep 16, 2021 at 9:26 AM Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Jon Nettleton [mailto:jon@solid-run.com]
> > > Sent: 06 September 2021 20:51
> > > To: Robin Murphy <robin.murphy@arm.com>
> > > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>; Shameerali
> > > Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>; Laurentiu
> > > Tudor <laurentiu.tudor@nxp.com>; linux-arm-kernel
> > > <linux-arm-kernel@lists.infradead.org>; ACPI Devel Maling List
> > > <linux-acpi@vger.kernel.org>; Linux IOMMU
> > > <iommu@lists.linux-foundation.org>; Linuxarm <linuxarm@huawei.com>;
> > > Joerg Roedel <joro@8bytes.org>; Will Deacon <will@kernel.org>;
> > > wanghuiqiang <wanghuiqiang@huawei.com>; Guohanjun (Hanjun Guo)
> > > <guohanjun@huawei.com>; Steven Price <steven.price@arm.com>; Sami
> > > Mujawar <Sami.Mujawar@arm.com>; Eric Auger
> <eric.auger@redhat.com>;
> > > yangyicong <yangyicong@huawei.com>
> > > Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node
> > > parsing
> > >
> > [...]
> >
> > > > >
> > > > > On the prot value assignment based on the remapping flag, I'd
> > > > > like to hear Robin/Joerg's opinion, I'd avoid being in a
> > > > > situation where "normally" this would work but then we have to quirk
> it.
> > > > >
> > > > > Is this a valid assumption _always_ ?
> > > >
> > > > No. Certainly applying IOMMU_CACHE without reference to the
> > > > device's _CCA attribute or how CPUs may be accessing a shared
> > > > buffer could lead to a loss of coherency. At worst, applying
> > > > IOMMU_MMIO to a device-private buffer *could* cause the device to
> > > > lose coherency with itself if the memory underlying the RMR may
> > > > have allocated into system caches. Note that the expected use for
> > > > non-remappable RMRs is the device holding some sort of long-lived
> > > > private data in system RAM - the MSI doorbell trick is far more of a niche
> hack really.
> > > >
> > > > At the very least I think we need to refer to the device's memory
> > > > access properties here.
> > > >
> > > > Jon, Laurentiu - how do RMRs correspond to the EFI memory map on
> > > > your firmware? I'm starting to think that as long as the
> > > > underlying memory is described appropriately there then we should
> > > > be able to infer correct attributes from the EFI memory type and flags.
> > >
> > > The devices are all cache coherent and marked as _CCA, 1.  The
> > > Memory regions are in the virt table as
> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE.
> > >
> > > The current chicken and egg problem we have is that during the
> > > fsl-mc-bus initialization we call
> > >
> > > error = acpi_dma_configure_id(&pdev->dev, DEV_DMA_COHERENT,
> > >                                               &mc_stream_id);
> > >
> > > which gets deferred because the SMMU has not been initialized yet.
> > > Then we initialize the RMR tables but there is no device reference
> > > there to be able to query device properties, only the stream id.
> > > After the IORT tables are parsed and the SMMU is setup, on the
> > > second device probe we associate everything based on the stream id
> > > and the fsl-mc-bus device is able to claim its 1-1 DMA mappings.
> >
> > Can we solve this order problem by delaying the
> > iommu_alloc_resv_region() to the iommu_dma_get_rmr_resv_regions(dev,
> > list) ? We could invoke
> > device_get_dma_attr() from there which I believe will return the _CCA
> attribute.
> >
> > Or is that still early to invoke that?
> 
> That looks like it should work. Do we then also need to parse through the
> VirtualMemoryTable matching the start and end addresses to determine the
> other memory attributes like MMIO?

Yes. But that looks tricky as I can't find that readily available on Arm, like the
efi_mem_attributes(). I will take a look.

Please let me know if there is one or any other easy way to retrieve it.

Thanks,
Shameer

> 
> -Jon
> 
> >
> > Thanks,
> > Shameer
> >
> > > cat /sys/kernel/iommu_groups/0/reserved_regions
> > > 0x0000000001000000 0x0000000010ffffff direct-relaxable
> > > 0x0000000008000000 0x00000000080fffff msi
> > > 0x000000080c000000 0x000000081bffffff direct-relaxable
> > > 0x0000001c00000000 0x0000001c001fffff direct-relaxable
> > > 0x0000002080000000 0x000000209fffffff direct-relaxable
> > >
> > > -Jon
> > >
> > > >
> > > > Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
To: Jon Nettleton <jon@solid-run.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Laurentiu Tudor <laurentiu.tudor@nxp.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"ACPI Devel Maling List" <linux-acpi@vger.kernel.org>,
	Linux IOMMU <iommu@lists.linux-foundation.org>,
	Joerg Roedel <joro@8bytes.org>, "Will Deacon" <will@kernel.org>,
	wanghuiqiang <wanghuiqiang@huawei.com>,
	"Guohanjun (Hanjun Guo)" <guohanjun@huawei.com>,
	Steven Price <steven.price@arm.com>,
	Sami Mujawar <Sami.Mujawar@arm.com>,
	Eric Auger <eric.auger@redhat.com>,
	yangyicong <yangyicong@huawei.com>
Subject: RE: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing
Date: Thu, 16 Sep 2021 08:26:14 +0000	[thread overview]
Message-ID: <e02a00a10ea3440dab1f9f9320de42ad@huawei.com> (raw)
In-Reply-To: <CABdtJHuEViN0MSz-ZJhR52+b=F6yvQ5mm_edVuLy1B=nHp+ESQ@mail.gmail.com>



> -----Original Message-----
> From: Jon Nettleton [mailto:jon@solid-run.com]
> Sent: 16 September 2021 08:52
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: Robin Murphy <robin.murphy@arm.com>; Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com>; Laurentiu Tudor <laurentiu.tudor@nxp.com>;
> linux-arm-kernel <linux-arm-kernel@lists.infradead.org>; ACPI Devel Maling
> List <linux-acpi@vger.kernel.org>; Linux IOMMU
> <iommu@lists.linux-foundation.org>; Joerg Roedel <joro@8bytes.org>; Will
> Deacon <will@kernel.org>; wanghuiqiang <wanghuiqiang@huawei.com>;
> Guohanjun (Hanjun Guo) <guohanjun@huawei.com>; Steven Price
> <steven.price@arm.com>; Sami Mujawar <Sami.Mujawar@arm.com>; Eric
> Auger <eric.auger@redhat.com>; yangyicong <yangyicong@huawei.com>
> Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing
> 
> On Thu, Sep 16, 2021 at 9:26 AM Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Jon Nettleton [mailto:jon@solid-run.com]
> > > Sent: 06 September 2021 20:51
> > > To: Robin Murphy <robin.murphy@arm.com>
> > > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>; Shameerali
> > > Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>; Laurentiu
> > > Tudor <laurentiu.tudor@nxp.com>; linux-arm-kernel
> > > <linux-arm-kernel@lists.infradead.org>; ACPI Devel Maling List
> > > <linux-acpi@vger.kernel.org>; Linux IOMMU
> > > <iommu@lists.linux-foundation.org>; Linuxarm <linuxarm@huawei.com>;
> > > Joerg Roedel <joro@8bytes.org>; Will Deacon <will@kernel.org>;
> > > wanghuiqiang <wanghuiqiang@huawei.com>; Guohanjun (Hanjun Guo)
> > > <guohanjun@huawei.com>; Steven Price <steven.price@arm.com>; Sami
> > > Mujawar <Sami.Mujawar@arm.com>; Eric Auger
> <eric.auger@redhat.com>;
> > > yangyicong <yangyicong@huawei.com>
> > > Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node
> > > parsing
> > >
> > [...]
> >
> > > > >
> > > > > On the prot value assignment based on the remapping flag, I'd
> > > > > like to hear Robin/Joerg's opinion, I'd avoid being in a
> > > > > situation where "normally" this would work but then we have to quirk
> it.
> > > > >
> > > > > Is this a valid assumption _always_ ?
> > > >
> > > > No. Certainly applying IOMMU_CACHE without reference to the
> > > > device's _CCA attribute or how CPUs may be accessing a shared
> > > > buffer could lead to a loss of coherency. At worst, applying
> > > > IOMMU_MMIO to a device-private buffer *could* cause the device to
> > > > lose coherency with itself if the memory underlying the RMR may
> > > > have allocated into system caches. Note that the expected use for
> > > > non-remappable RMRs is the device holding some sort of long-lived
> > > > private data in system RAM - the MSI doorbell trick is far more of a niche
> hack really.
> > > >
> > > > At the very least I think we need to refer to the device's memory
> > > > access properties here.
> > > >
> > > > Jon, Laurentiu - how do RMRs correspond to the EFI memory map on
> > > > your firmware? I'm starting to think that as long as the
> > > > underlying memory is described appropriately there then we should
> > > > be able to infer correct attributes from the EFI memory type and flags.
> > >
> > > The devices are all cache coherent and marked as _CCA, 1.  The
> > > Memory regions are in the virt table as
> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE.
> > >
> > > The current chicken and egg problem we have is that during the
> > > fsl-mc-bus initialization we call
> > >
> > > error = acpi_dma_configure_id(&pdev->dev, DEV_DMA_COHERENT,
> > >                                               &mc_stream_id);
> > >
> > > which gets deferred because the SMMU has not been initialized yet.
> > > Then we initialize the RMR tables but there is no device reference
> > > there to be able to query device properties, only the stream id.
> > > After the IORT tables are parsed and the SMMU is setup, on the
> > > second device probe we associate everything based on the stream id
> > > and the fsl-mc-bus device is able to claim its 1-1 DMA mappings.
> >
> > Can we solve this order problem by delaying the
> > iommu_alloc_resv_region() to the iommu_dma_get_rmr_resv_regions(dev,
> > list) ? We could invoke
> > device_get_dma_attr() from there which I believe will return the _CCA
> attribute.
> >
> > Or is that still early to invoke that?
> 
> That looks like it should work. Do we then also need to parse through the
> VirtualMemoryTable matching the start and end addresses to determine the
> other memory attributes like MMIO?

Yes. But that looks tricky as I can't find that readily available on Arm, like the
efi_mem_attributes(). I will take a look.

Please let me know if there is one or any other easy way to retrieve it.

Thanks,
Shameer

> 
> -Jon
> 
> >
> > Thanks,
> > Shameer
> >
> > > cat /sys/kernel/iommu_groups/0/reserved_regions
> > > 0x0000000001000000 0x0000000010ffffff direct-relaxable
> > > 0x0000000008000000 0x00000000080fffff msi
> > > 0x000000080c000000 0x000000081bffffff direct-relaxable
> > > 0x0000001c00000000 0x0000001c001fffff direct-relaxable
> > > 0x0000002080000000 0x000000209fffffff direct-relaxable
> > >
> > > -Jon
> > >
> > > >
> > > > Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-09-16  8:26 UTC|newest]

Thread overview: 150+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-05  8:07 [PATCH v7 0/9] ACPI/IORT: Support for IORT RMR node Shameer Kolothum
2021-08-05  8:07 ` Shameer Kolothum
2021-08-05  8:07 ` Shameer Kolothum
2021-08-05  8:07 ` [PATCH v7 1/9] iommu: Introduce a union to struct iommu_resv_region Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-20 10:22   ` Steven Price
2021-08-20 10:22     ` Steven Price
2021-08-20 10:22     ` Steven Price
2021-10-08 12:14   ` Robin Murphy
2021-10-08 12:14     ` Robin Murphy
2021-10-08 12:14     ` Robin Murphy
2021-10-09  6:57     ` Jon Nettleton
2021-10-09  6:57       ` Jon Nettleton
2021-10-09  6:57       ` Jon Nettleton
2021-10-11  5:47       ` Shameerali Kolothum Thodi
2021-10-11  5:47         ` Shameerali Kolothum Thodi
2021-10-11  5:47         ` Shameerali Kolothum Thodi
2021-10-11 13:47         ` Robin Murphy
2021-10-11 13:47           ` Robin Murphy
2021-10-11 13:47           ` Robin Murphy
2021-08-05  8:07 ` [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05 16:03   ` Lorenzo Pieralisi
2021-08-05 16:03     ` Lorenzo Pieralisi
2021-08-05 16:03     ` Lorenzo Pieralisi
2021-08-05 16:31     ` Jon Nettleton
2021-08-05 16:31       ` Jon Nettleton
2021-08-05 16:31       ` Jon Nettleton
2021-08-05 18:37     ` Laurentiu Tudor
2021-08-05 18:37       ` Laurentiu Tudor
2021-08-05 18:37       ` Laurentiu Tudor
2021-09-06 17:44     ` Robin Murphy
2021-09-06 17:44       ` Robin Murphy
2021-09-06 17:44       ` Robin Murphy
2021-09-06 19:51       ` Jon Nettleton
2021-09-06 19:51         ` Jon Nettleton
2021-09-06 19:51         ` Jon Nettleton
2021-09-16  7:26         ` Shameerali Kolothum Thodi
2021-09-16  7:26           ` Shameerali Kolothum Thodi
2021-09-16  7:26           ` Shameerali Kolothum Thodi
2021-09-16  7:52           ` Jon Nettleton
2021-09-16  7:52             ` Jon Nettleton
2021-09-16  7:52             ` Jon Nettleton
2021-09-16  8:26             ` Shameerali Kolothum Thodi [this message]
2021-09-16  8:26               ` Shameerali Kolothum Thodi
2021-09-16  8:26               ` Shameerali Kolothum Thodi
2021-09-16 11:16               ` Jon Nettleton
2021-09-16 11:16                 ` Jon Nettleton
2021-09-16 11:16                 ` Jon Nettleton
2021-09-17 11:26                 ` Shameerali Kolothum Thodi
2021-09-17 11:26                   ` Shameerali Kolothum Thodi
2021-09-17 11:26                   ` Shameerali Kolothum Thodi
2021-10-05 10:53                   ` Laurentiu Tudor
2021-10-05 10:53                     ` Laurentiu Tudor
2021-10-05 10:53                     ` Laurentiu Tudor
2021-10-08 12:48   ` Robin Murphy
2021-10-08 12:48     ` Robin Murphy
2021-10-08 12:48     ` Robin Murphy
2021-10-09  7:06     ` Jon Nettleton
2021-10-09  7:06       ` Jon Nettleton
2021-10-09  7:06       ` Jon Nettleton
2021-10-11 14:04       ` Robin Murphy
2021-10-11 14:04         ` Robin Murphy
2021-10-11 14:04         ` Robin Murphy
2021-10-12  8:00         ` Jon Nettleton
2021-10-12  8:00           ` Jon Nettleton
2021-10-12  8:00           ` Jon Nettleton
2021-12-08 12:18           ` Lorenzo Pieralisi
2021-12-08 12:18             ` Lorenzo Pieralisi
2021-12-08 12:18             ` Lorenzo Pieralisi
2021-12-08 13:26             ` Jon Nettleton
2021-12-08 13:26               ` Jon Nettleton
2021-12-08 13:26               ` Jon Nettleton
2021-12-08 14:37               ` Robin Murphy
2021-12-08 14:37                 ` Robin Murphy
2021-12-08 14:37                 ` Robin Murphy
2021-12-08 15:11                 ` Jon Nettleton
2021-12-08 15:11                   ` Jon Nettleton
2021-12-08 15:11                   ` Jon Nettleton
2021-10-11  5:59     ` Shameerali Kolothum Thodi
2021-10-11  5:59       ` Shameerali Kolothum Thodi
2021-10-11  5:59       ` Shameerali Kolothum Thodi
2021-08-05  8:07 ` [PATCH v7 3/9] iommu/dma: Introduce generic helper to retrieve RMR info Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-10-08 13:03   ` Robin Murphy
2021-10-08 13:03     ` Robin Murphy
2021-10-08 13:03     ` Robin Murphy
2021-10-11  5:51     ` Shameerali Kolothum Thodi
2021-10-11  5:51       ` Shameerali Kolothum Thodi
2021-10-11  5:51       ` Shameerali Kolothum Thodi
2021-08-05  8:07 ` [PATCH v7 4/9] ACPI/IORT: Add a helper to retrieve RMR memory regions Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05 15:43   ` Lorenzo Pieralisi
2021-08-05 15:43     ` Lorenzo Pieralisi
2021-08-05 15:43     ` Lorenzo Pieralisi
2021-08-05  8:07 ` [PATCH v7 5/9] iommu/arm-smmu-v3: Introduce strtab init helper Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07 ` [PATCH v7 6/9] iommu/arm-smmu-v3: Refactor arm_smmu_init_bypass_stes() to force bypass Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07 ` [PATCH v7 7/9] iommu/arm-smmu-v3: Get associated RMR info and install bypass STE Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07 ` [PATCH v7 8/9] iommu/arm-smmu: Get associated RMR info and install bypass SMR Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07 ` [PATCH v7 9/9] iommu/dma: Reserve any RMR regions associated with a dev Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-08-05  8:07   ` Shameer Kolothum
2021-10-08 13:09   ` Robin Murphy
2021-10-08 13:09     ` Robin Murphy
2021-10-08 13:09     ` Robin Murphy
2021-10-09  7:07     ` Jon Nettleton
2021-10-09  7:07       ` Jon Nettleton
2021-10-09  7:07       ` Jon Nettleton
2021-10-11 15:00       ` Robin Murphy
2021-10-11 15:00         ` Robin Murphy
2021-10-11 15:00         ` Robin Murphy
2021-10-11 15:42         ` Shameerali Kolothum Thodi
2021-10-11 15:42           ` Shameerali Kolothum Thodi
2021-10-11 15:42           ` Shameerali Kolothum Thodi
2021-08-05 13:22 ` [PATCH v7 0/9] ACPI/IORT: Support for IORT RMR node Ard Biesheuvel
2021-08-05 13:22   ` Ard Biesheuvel
2021-08-05 13:22   ` Ard Biesheuvel
2021-08-05 13:35   ` Shameerali Kolothum Thodi
2021-08-05 13:35     ` Shameerali Kolothum Thodi
2021-08-05 13:35     ` Shameerali Kolothum Thodi
2021-08-05 14:09     ` Ard Biesheuvel
2021-08-05 14:09       ` Ard Biesheuvel
2021-08-05 14:09       ` Ard Biesheuvel
2021-08-31  5:06       ` Jon Nettleton
2021-08-31  5:06         ` Jon Nettleton
2021-08-31  5:06         ` Jon Nettleton
2021-09-30  9:47 ` Eric Auger
2021-09-30  9:47   ` Eric Auger
2021-09-30  9:47   ` Eric Auger
2021-09-30 10:50   ` Shameerali Kolothum Thodi
2021-09-30 10:50     ` Shameerali Kolothum Thodi
2021-09-30 10:50     ` Shameerali Kolothum Thodi
2022-01-25 13:00 ` Shameerali Kolothum Thodi via iommu
2022-01-25 13:00   ` Shameerali Kolothum Thodi
2022-01-25 13:00   ` Shameerali Kolothum Thodi
2022-01-25 19:30   ` Robin Murphy
2022-01-25 19:30     ` Robin Murphy
2022-01-25 19:30     ` Robin Murphy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e02a00a10ea3440dab1f9f9320de42ad@huawei.com \
    --to=shameerali.kolothum.thodi@huawei.com \
    --cc=Sami.Mujawar@arm.com \
    --cc=eric.auger@redhat.com \
    --cc=guohanjun@huawei.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jon@solid-run.com \
    --cc=joro@8bytes.org \
    --cc=laurentiu.tudor@nxp.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=robin.murphy@arm.com \
    --cc=steven.price@arm.com \
    --cc=wanghuiqiang@huawei.com \
    --cc=will@kernel.org \
    --cc=yangyicong@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.