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

[Lorenzo Pieralisi]

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@xxxxxxx
> >v1: http://lkml.kernel.org/r/20170720144517.32529-1-lorenzo.pieralisi@xxxxxxx
> >
> >-- Original cover letter --
> >
> >As reported in:
> >
> >http://lkml.kernel.org/r/CAL85gmA_SSCwM80TKdkZqEe+S1beWzDEvdki1kpkmUTDRmSP7g@xxxxxxxxxxxxxx
> >
> >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@xxxxxxx>
> >Cc: Hanjun Guo <hanjun.guo@xxxxxxxxxx>
> >Cc: Feng Kan <fkan@xxxxxxx>
> >Cc: Jon Masters <jcm@xxxxxxxxxx>
> >Cc: Robert Moore <robert.moore@xxxxxxxxx>
> >Cc: Robin Murphy <robin.murphy@xxxxxxx>
> >Cc: Zhang Rui <rui.zhang@xxxxxxxxx>
> >Cc: "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx>
> >
> >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@xxxxxxx>

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