[PATCH v3 0/5] ACPI: DMA ranges management

Lorenzo Pieralisi lorenzo.pieralisi at arm.com
Fri Aug 11 01:52:07 PDT 2017


On Wed, Aug 09, 2017 at 04:14:43PM -0500, Jeremy Linton wrote:
> Hi,
> 
> Better late than never I guess..
> 
> On 08/03/2017 07:32 AM, Lorenzo Pieralisi wrote:
> >This patch series is v3 of a previous posting:
> >
> >v2->v3:
> >	- Fixed DMA masks computation
> >         - Fixed size computation overflow in acpi_dma_get_range()
> >
> >v1->v2:
> >	- Reworked acpi_dma_get_range() flow and logs
> >	- Added IORT named component address limits
> >	- Renamed acpi_dev_get_resources() helper function
> >	- Rebased against v4.13-rc3
> >
> >v2: http://lkml.kernel.org/r/20170731152323.32488-1-lorenzo.pieralisi@arm.com
> >v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieralisi@arm.com
> >
> >-- Original cover letter --
> >
> >As reported in:
> >
> >http://lkml.kernel.org/r/CAL85gmA_SSCwM80TKdkZqEe+S1beWzDEvdki1kpkmUTDRmSP7g@mail.gmail.com
> >
> >the bus connecting devices to an IOMMU bus can be smaller in size than
> >the IOMMU input address bits which results in devices DMA HW bugs in
> >particular related to IOVA allocation (ie chopping of higher address
> >bits owing to system bus HW capabilities mismatch with the IOMMU).
> >
> >Fortunately this problem can be solved through an already present but never
> >used ACPI 6.2 firmware bindings (ie _DMA object) allowing to define the DMA
> >window for a specific bus in ACPI and therefore all upstream devices
> >connected to it.
> >
> >This small patch series enables _DMA parsing in ACPI core code and
> >use it in ACPI IORT code in order to detect DMA ranges for devices and
> >update their data structures to make them work with their related DMA
> >addressing restrictions.
> >
> >Cc: Will Deacon <will.deacon at arm.com>
> >Cc: Hanjun Guo <hanjun.guo at linaro.org>
> >Cc: Feng Kan <fkan at apm.com>
> >Cc: Jon Masters <jcm at redhat.com>
> >Cc: Robert Moore <robert.moore at intel.com>
> >Cc: Robin Murphy <robin.murphy at arm.com>
> >Cc: Zhang Rui <rui.zhang at intel.com>
> >Cc: "Rafael J. Wysocki" <rjw at rjwysocki.net>
> >
> >Lorenzo Pieralisi (5):
> >   ACPICA: resource_mgr: Allow _DMA method in walk resources
> >   ACPI: Make acpi_dev_get_resources() method agnostic
> >   ACPI: Introduce DMA ranges parsing
> >   ACPI: Make acpi_dma_configure() DMA regions aware
> >   ACPI/IORT: Add IORT named component memory address limits
> >
> >  drivers/acpi/acpica/rsxface.c |  7 ++--
> >  drivers/acpi/arm64/iort.c     | 57 ++++++++++++++++++++++++++-
> >  drivers/acpi/resource.c       | 82 +++++++++++++++++++++++++++++---------
> >  drivers/acpi/scan.c           | 91 +++++++++++++++++++++++++++++++++++++++----
> >  include/acpi/acnames.h        |  1 +
> >  include/acpi/acpi_bus.h       |  2 +
> >  include/linux/acpi.h          |  8 ++++
> >  include/linux/acpi_iort.h     |  5 ++-
> >  8 files changed, 219 insertions(+), 34 deletions(-)
> 
> Ok, despite being merged already I think its worthwhile to say that
> I've been testing this with:
> 
> Method(_DMA, 0, Serialized)
> {
> 	Return (ResourceTemplate()
> 	{
> 		QWORDMemory(
> 		ResourceConsumer,

I asked to update the ACPI specifications because this should be
ResourceProducer, we need an errata to sort this out before it
becomes a problem.

> 		PosDecode,          // _DEC
> 		MinFixed,           // _MIF
> 		MaxFixed,           // _MAF
> 		Prefetchable,       // _MEM
> 		ReadWrite,          // _RW
> 		0,                  // _GRA
> 		0x10000000,         // _MIN
> 		0x1fffffff,         // _MAX
> 		0x000000000,        // _TRA
> 		0x10000000,         // _LEN
> 		,
> 		,
> 		,
> 		)
> 	})
> } // Method(_DMA)
> 
> (and a couple minor variations)
> 
> and a fair number of debug statements sprinkled around to verify
> that the IOVAs are appropriately limited. So I don't see anything
> wrong with the code and it appears to work and the devices behind a
> bridge limited like this continue to work as long as sane values are
> placed in the min/max/len fields.
> 
> Thanks,
> 
> Tested-by: Jeremy Linton <jeremy.linton at arm.com>

Thank you very much Jeremy for testing it, appreciated please let me
know if you spot anything wrong with it on the machines you are
running tests on.

Lorenzo



More information about the linux-arm-kernel mailing list