From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (NAM02-SN1-obe.outbound.protection.outlook.com [40.107.77.89]) by mx.groups.io with SMTP id smtpd.web12.22371.1602437112066626161 for ; Sun, 11 Oct 2020 10:25:12 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@vmware.com header.s=selector2 header.b=KEK54wj1; spf=pass (domain: vmware.com, ip: 40.107.77.89, mailfrom: awarkentin@vmware.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q3zWUnbF7XSd6fEOBDGkRzNMxySyvGgV0QdH64yBErUvnlGcEf9XvVK54nwAcotv//DteIo63O6ZGsH6kR0Kczl0BjUTdLgWrbgTOsXixosZtAFqclwVnV5RHSncLePRyY/ayicfOoVLYZ8wrpNjWqNEh2blqTD4a8hc5zrFhfn+jp361SS2u0+BCwJ/30VNF/brfeQNESYEMv00JFC2SjPEvzfWXTmv5IH3zoGmJsxioJmz7MgnBWxRFyh1hDD3ZOWe02aAls88hgZ9G9POw51yx0LX6djCElcKWMMZOEzDPAqBFO+KBL1ZK1lFIUsKV6yP+vpdpZhFsOL0vhBRvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VqUbFfPVIKZwKmhUzjbP3eJgVwE1erd4cUtS+EMeeR8=; b=A5Gzo3HCcIaBYB4LWmfIUqYp297bj95R1R37b6dTtZHPdUF0kZb/xK6aqsYU9nR32aRHXFTFGdmmtpxy0iAk09pqabEwLo4q8uf+3TzMv2rDsPVBgGaMOqF1WF++/M3lMgB3VUUADM2XtiVY08iEcEgwl5D3GsvS3fUc6DCfvbPsLUW66bakxU++pxmFzUbvWbgSyE8svZN53J0z7nPqqDCkqdkaavT9XuiUg29bRQSFsSlIny7xEkrY9xMMEePGdphZ7EzPSOMslWRvvn0Osd75KIVrnjX5SeBcOCvRmeAvHCtGlURygvxlVYiw/XeS0hJob9rTy2zF/vQOBvReyg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vmware.com; dmarc=pass action=none header.from=vmware.com; dkim=pass header.d=vmware.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vmware.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VqUbFfPVIKZwKmhUzjbP3eJgVwE1erd4cUtS+EMeeR8=; b=KEK54wj1wSVLD08OLwxtlNKgTLixvkzVnq0KV4rfkpWMR9jKM6M8J34O7XQe9vyjetoMF4jkCds6JymTTC2h/ywkEwMmSL1h2WR2OmOfmg905AH3u+0/Xyjj4o/6YjDOgMnrUIXr73DO7wQ2bwn9T2WouSSWjkilmSyIa7lF8Dc= Received: from BN6PR05MB3411.namprd05.prod.outlook.com (2603:10b6:405:43::23) by BN7PR05MB5731.namprd05.prod.outlook.com (2603:10b6:408:e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.11; Sun, 11 Oct 2020 17:25:10 +0000 Received: from BN6PR05MB3411.namprd05.prod.outlook.com ([fe80::b03c:e0bf:2c43:f362]) by BN6PR05MB3411.namprd05.prod.outlook.com ([fe80::b03c:e0bf:2c43:f362%2]) with mapi id 15.20.3477.018; Sun, 11 Oct 2020 17:25:09 +0000 From: "Andrei Warkentin" To: Ard Biesheuvel , "devel@edk2.groups.io" CC: Samer El-Haj-Mahmoud , Jeremy Linton , Pete Batard , Leif Lindholm Subject: Re: [PATCH edk2-platforms 1/1] Platform/RaspberryPi/AcpiTables: add a IORT ACPI table to limit XHCI DMA Thread-Topic: [PATCH edk2-platforms 1/1] Platform/RaspberryPi/AcpiTables: add a IORT ACPI table to limit XHCI DMA Thread-Index: AQHWn6d8viDnv/OdskKMzEMDMg0D6KmSptyK Date: Sun, 11 Oct 2020 17:25:09 +0000 Message-ID: References: <20201011082057.20662-1-ard.biesheuvel@arm.com> In-Reply-To: <20201011082057.20662-1-ard.biesheuvel@arm.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=vmware.com; x-originating-ip: [199.27.253.191] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 24a0c407-d240-40dc-ef0e-08d86e0a9ad5 x-ms-traffictypediagnostic: BN7PR05MB5731: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Qiczf4exzQT3PDUEGRaG4sV9hHETgmz7u03m94M/YJL8vmD4zu2XWGSMTJUCvcg1/NCZeNTB7+xDyd5iQ/mwPDEAP61vEx/mXJVIfC11X54lHz44gsJn0dxfasxjtEE0SUVGnlLP0FD/8aNR0+iSwtN6eHtPXPPGsQgDQbHHkWGOkikTV1mg4DCYXYhcF2lS8e8adYjuMilGP6h2NqygfLjoe0mHaeQJ9yu7KH60qCKmHQRQaxyVs6Dq3Bo8qBo4mAjmQbIJNPxbNUoKGmgIGIgC//uqx3/MhjL4DX4XPxaAGbPhjZ8mu2XrAK/nBRBrLRGWgs+nd+ebT10mL3Drtcqv86tEY3dux3U8/hFwmjPScJowqfnCflm45m2axGa/1qFsQzFhruOb9/APt++G3g== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BN6PR05MB3411.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(136003)(366004)(396003)(376002)(346002)(39860400002)(83080400001)(166002)(8936002)(33656002)(478600001)(5660300002)(86362001)(71200400001)(6506007)(4326008)(8676002)(9686003)(66946007)(66446008)(64756008)(7696005)(53546011)(45080400002)(76116006)(316002)(52536014)(966005)(110136005)(54906003)(19627405001)(26005)(186003)(66556008)(55016002)(66476007)(83380400001)(2906002);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata: ZpAtrySRgbOKKDk88lCh62Aktgdf7ZAGDld+aSHYaXwO62TJxAIY9zAu5xyaOIQ9zPRxVV/h7qHorJHJCUmLoeTqez17TtAk5ZEDPplnfLWB+zHOagQXM+mHWECOk3PyNkh9mmmXGhw6anLWX0XpQhUK0B4P/Sskuvjt6Kb3jlAcOLIblAaFHH4VNsVM3butdqPIoL5FabRGsDUFvDqv1bdnPA53hDZNDuhfSVuYHEL9662ywHsB2KxnxKxoBmklw1ViHrwYJYTa1nhIrcQfcSjDb32uJ9X4M+KVkPj3xZGr9CHfYl0g0vCvPSlQy65WTFPxRxVa103b6UVtMWUyGLGN3GvD0RvtLuwmBsfpzS2JWdBcGQnTp31c57oK+9zqQklpWDavtXJcfvR97O/r1VipltjNSfGf3dSEsQxDCwTPOPofJtYLQ6DMLjQua3d9kjvP7JelOqnyggqLQuwjG6JOUXALCN3IawSjc9Qh9z2oRK85yUdTLL7k4Ch9yH/Nq4THilplCuUe8ARPSznGAc/c4b13nF9RSBhSY3J1tsCNcvuBKJCAPpS4D/PP2L2VLPLjItCQy1Vc0IOC4UpQ5nbPiJZ4g9Ccwi6LZEapzKIZRLd5jMBi1HS+Ewg69yP9s2Vo9QGtSqSPs8bftFJN4A== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR05MB3411.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 24a0c407-d240-40dc-ef0e-08d86e0a9ad5 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2020 17:25:09.6047 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yHZnGKEfNdZJs9ttIBQMq/98jcm+bTyOAfMppMf+BpIlQVvPR/2UwcRjZfp4OCLhll2T3FbqWzX6iqqWftDPkw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB5731 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_BN6PR05MB3411DC16A5BF5FB524D3ABC4B9060BN6PR05MB3411namp_" --_000_BN6PR05MB3411DC16A5BF5FB524D3ABC4B9060BN6PR05MB3411namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ard, This makes sense to me. Glad there's a way forward to support such systems = with ACPI in Linux. Could the other "legacy" devices behind the GPU be handled similarly? I mea= n the ones with the 1GB DMA limit. Not this change, of course. Reviewed-by: Andrei Warkentin A ________________________________ From: Ard Biesheuvel Sent: Sunday, October 11, 2020 3:20 AM To: devel@edk2.groups.io Cc: Ard Biesheuvel ; Samer El-Haj-Mahmoud ; Jeremy Linton ; Pete Batard <= pete@akeo.ie>; Andrei Warkentin ; Leif Lindholm Subject: [PATCH edk2-platforms 1/1] Platform/RaspberryPi/AcpiTables: add a = IORT ACPI table to limit XHCI DMA Add an IORT table that will limit XHCI DMA to 2 GB, by setting the DMA width to 31 bits. This is needed for Linux/arm64, which can only reliably deal with devices that are unable to perform DMA to the entire 32-bit address range if it can discover their existence early during boot, and this is before the ACPI interpreter is up and running (which rules out calling the _DMA method of the XHC0 object) Cc: Samer El-Haj-Mahmoud Cc: Jeremy Linton Cc: Pete Batard Cc: Andrei Warkentin Cc: Leif Lindholm Signed-off-by: Ard Biesheuvel --- Related discussions here: https://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flore.ke= rnel.org%2Flinux-arm-kernel%2F20201001161740.29064-1-nsaenzjulienne%40suse.= de%2F&data=3D04%7C01%7Cawarkentin%40vmware.com%7C0ceb573430144cf5a9c308= d86dbe9d15%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637380012741008284%= 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw= iLCJXVCI6Mn0%3D%7C3000&sdata=3DZ1MavubU27xkVXFXSSLtobrwpKSmerA9y9uRZNDd= 2Nw%3D&reserved=3D0 https://nam04.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flore.ke= rnel.org%2Flinux-acpi%2F20201010093153.30177-1-ardb%40kernel.org%2F&dat= a=3D04%7C01%7Cawarkentin%40vmware.com%7C0ceb573430144cf5a9c308d86dbe9d15%7C= b39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637380012741008284%7CUnknown%7CT= WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%= 3D%7C3000&sdata=3DJrfduAeqAJqiFzP8CrwnTigwy21SIJYviMW6IkdA8KI%3D&re= served=3D0 On Linux, a _DMA method supersedes the IORT, and so the 3 GB limit will be used at runtime. IOW, streaming DMA will be permitted to the entire 3 GB region, but if shared buffers or bounce buffers are needed, they will be allocated from the first 2 GB of DRAM. We may need to offer some guidance on this in the IORT spec, i.e., which value takes precedence if the IORT and the _DMA method disagree. Platform/RaspberryPi/AcpiTables/AcpiTables.inf | 1 + Platform/RaspberryPi/AcpiTables/Iort.aslc | 58 ++++++++++++++++++++ 2 files changed, 59 insertions(+) diff --git a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf b/Platform/Rasp= berryPi/AcpiTables/AcpiTables.inf index c40c32e16ff7..d2cce074e56c 100644 --- a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf +++ b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf @@ -29,6 +29,7 @@ [Sources] Fadt.aslc Dbg2.aslc Gtdt.aslc + Iort.aslc Dsdt.asl Csrt.aslc Spcr.aslc diff --git a/Platform/RaspberryPi/AcpiTables/Iort.aslc b/Platform/Raspberry= Pi/AcpiTables/Iort.aslc new file mode 100644 index 000000000000..1351e8f7b262 --- /dev/null +++ b/Platform/RaspberryPi/AcpiTables/Iort.aslc @@ -0,0 +1,58 @@ +/** @file + + Copyright (c) 2020, Arm, Ltd. All rights reserved.
+ + SPDX-License-Identifier: BSD-2-Clause-Patent + +**/ + +#include + +#include "AcpiTables.h" + +#pragma pack(1) + +typedef struct { + EFI_ACPI_6_0_IO_REMAPPING_NAMED_COMP_NODE Node; + CONST CHAR8 Name[16]; +} RPI4_NC_NODE; + +typedef struct { + EFI_ACPI_6_0_IO_REMAPPING_TABLE Iort; + RPI4_NC_NODE NamedCompNode; +} RPI4_IO_REMAPPING_STRUCTURE; + +STATIC RPI4_IO_REMAPPING_STRUCTURE Iort =3D { + { + ACPI_HEADER (EFI_ACPI_6_0_IO_REMAPPING_TABLE_SIGNATURE, + RPI4_IO_REMAPPING_STRUCTURE, + EFI_ACPI_IO_REMAPPING_TABLE_REVISION), + 1, // NumNodes + sizeof (EFI_ACPI_6_0_IO_REMAPPING_TABLE), // NodeOffset + 0 // Reserved + }, { + // XHCI named component node + { + { + EFI_ACPI_IORT_TYPE_NAMED_COMP, + sizeof (RPI4_NC_NODE), + 0x0, + 0x0, + 0x0, + 0x0, + }, + 0x0, + 0x0, + 0x0, + 0x0, + 0x0, + 31, + }, { + "\\_SB_.SCB0.XHC0" + } + } +}; + +#pragma pack() + +VOID* CONST ReferenceAcpiTable =3D &Iort; -- 2.17.1 --_000_BN6PR05MB3411DC16A5BF5FB524D3ABC4B9060BN6PR05MB3411namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Ard,

This makes sense to me. Glad there's a way forward to support such systems = with ACPI in Linux.

Could the other "legacy" devices behind the GPU be handled simila= rly? I mean the ones with the 1GB DMA limit. Not this change, of course.

Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>

A
From: Ard Biesheuvel <ar= d.biesheuvel@arm.com>
Sent: Sunday, October 11, 2020 3:20 AM
To: devel@edk2.groups.io <devel@edk2.groups.io>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>; Samer El-Haj-Mahm= oud <Samer.El-Haj-Mahmoud@arm.com>; Jeremy Linton <jeremy.linton@a= rm.com>; Pete Batard <pete@akeo.ie>; Andrei Warkentin <awarkent= in@vmware.com>; Leif Lindholm <leif@nuviainc.com>
Subject: [PATCH edk2-platforms 1/1] Platform/RaspberryPi/AcpiTables:= add a IORT ACPI table to limit XHCI DMA
 
Add an IORT table that will limit XHCI DMA to 2 GB= , by setting the
DMA width to 31 bits. This is needed for Linux/arm64, which can
only reliably deal with devices that are unable to perform DMA to
the entire 32-bit address range if it can discover their existence
early during boot, and this is before the ACPI interpreter is up
and running (which rules out calling the _DMA method of the XHC0
object)

Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Jeremy Linton <jeremy.linton@arm.com>
Cc: Pete Batard <pete@akeo.ie>
Cc: Andrei Warkentin <awarkentin@vmware.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
---
Related discussions here:

https://nam04.safelinks.pro= tection.outlook.com/?url=3Dhttps%3A%2F%2Flore.kernel.org%2Flinux-arm-kernel= %2F20201001161740.29064-1-nsaenzjulienne%40suse.de%2F&amp;data=3D04%7C0= 1%7Cawarkentin%40vmware.com%7C0ceb573430144cf5a9c308d86dbe9d15%7Cb39138ca3c= ee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637380012741008284%7CUnknown%7CTWFpbGZsb3d= 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&= amp;amp;sdata=3DZ1MavubU27xkVXFXSSLtobrwpKSmerA9y9uRZNDd2Nw%3D&amp;rese= rved=3D0
https://nam04.safelinks.protection.outlo= ok.com/?url=3Dhttps%3A%2F%2Flore.kernel.org%2Flinux-acpi%2F20201010093153.3= 0177-1-ardb%40kernel.org%2F&amp;data=3D04%7C01%7Cawarkentin%40vmware.co= m%7C0ceb573430144cf5a9c308d86dbe9d15%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0= %7C1%7C637380012741008284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI= joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3DJrfduAeqAJ= qiFzP8CrwnTigwy21SIJYviMW6IkdA8KI%3D&amp;reserved=3D0

On Linux, a _DMA method supersedes the IORT, and so the 3 GB limit will
be used at runtime. IOW, streaming DMA will be permitted to the entire
3 GB region, but if shared buffers or bounce buffers are needed, they
will be allocated from the first 2 GB of DRAM.

We may need to offer some guidance on this in the IORT spec, i.e., which value takes precedence if the IORT and the _DMA method disagree.

 Platform/RaspberryPi/AcpiTables/AcpiTables.inf |  1 +
 Platform/RaspberryPi/AcpiTables/Iort.aslc    &nbs= p; | 58 ++++++++++++++++++++
 2 files changed, 59 insertions(+)

diff --git a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf b/Platform/Rasp= berryPi/AcpiTables/AcpiTables.inf
index c40c32e16ff7..d2cce074e56c 100644
--- a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
+++ b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
@@ -29,6 +29,7 @@ [Sources]
   Fadt.aslc
   Dbg2.aslc
   Gtdt.aslc
+  Iort.aslc
   Dsdt.asl
   Csrt.aslc
   Spcr.aslc
diff --git a/Platform/RaspberryPi/AcpiTables/Iort.aslc b/Platform/Raspberry= Pi/AcpiTables/Iort.aslc
new file mode 100644
index 000000000000..1351e8f7b262
--- /dev/null
+++ b/Platform/RaspberryPi/AcpiTables/Iort.aslc
@@ -0,0 +1,58 @@
+/** @file
+
+  Copyright (c) 2020, Arm, Ltd. All rights reserved.<BR>
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include <IndustryStandard/IoRemappingTable.h>
+
+#include "AcpiTables.h"
+
+#pragma pack(1)
+
+typedef struct {
+  EFI_ACPI_6_0_IO_REMAPPING_NAMED_COMP_NODE Node;
+  CONST CHAR8         &n= bsp;            = ;         Name[16];
+} RPI4_NC_NODE;
+
+typedef struct {
+  EFI_ACPI_6_0_IO_REMAPPING_TABLE      Iort;=
+  RPI4_NC_NODE         &= nbsp;           &nbs= p;   NamedCompNode;
+} RPI4_IO_REMAPPING_STRUCTURE;
+
+STATIC RPI4_IO_REMAPPING_STRUCTURE Iort =3D {
+  {
+    ACPI_HEADER (EFI_ACPI_6_0_IO_REMAPPING_TABLE_SIGNATURE,=
+            &n= bsp;    RPI4_IO_REMAPPING_STRUCTURE,
+            &n= bsp;    EFI_ACPI_IO_REMAPPING_TABLE_REVISION),
+    1,         = ;            &n= bsp;            = ;            // NumN= odes
+    sizeof (EFI_ACPI_6_0_IO_REMAPPING_TABLE),  &n= bsp;    // NodeOffset
+    0         =             &nb= sp;            =              //= Reserved
+  }, {
+    // XHCI named component node
+    {
+      {
+        EFI_ACPI_IORT_TYPE_NAMED_COMP,<= br> +        sizeof (RPI4_NC_NODE),
+        0x0,
+        0x0,
+        0x0,
+        0x0,
+      },
+      0x0,
+      0x0,
+      0x0,
+      0x0,
+      0x0,
+      31,
+    }, {
+      "\\_SB_.SCB0.XHC0"
+    }
+  }
+};
+
+#pragma pack()
+
+VOID* CONST ReferenceAcpiTable =3D &Iort;
--
2.17.1

--_000_BN6PR05MB3411DC16A5BF5FB524D3ABC4B9060BN6PR05MB3411namp_--