From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) by mx.groups.io with SMTP id smtpd.web09.3439.1572540246216701668 for ; Thu, 31 Oct 2019 09:44:06 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=cYZwJhQ2; spf=pass (domain: apple.com, ip: 17.151.62.67, mailfrom: afish@apple.com) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x9VGbNF7023593; Thu, 31 Oct 2019 09:44:04 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : content-transfer-encoding : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=Aqy+ReClmbxnpDj4fAHHjHKQ8adzm5+ydDAK+oFTsvQ=; b=cYZwJhQ2z19AImktabWB3ZMkOhDJfgvrLqJFvcZlsfO3RUhrOoFWmS907dXi4pWveyB2 HkoRddPU1UOJOS6ABB1PMV5rmFH0cxjU3eSRdwzwligL0sH/YajUV+A/u4c7EdsygM4W P1czBS159+Y/BRKFL8dRVqEK9y9RoWdZYc1WxdvNi8P41ZW8xplEzlHIeU3Rjl+1ok5J iQLIFHGKoOY8CUOB3wha8S+hZqqHo/C/YV1fnzM+1iFq+qEWA4vlUQ0BX44Y8iFOrNKs mvYPO6slUI3yQ4dyyCqHjvsemMeeUmq/BsJsLTtxhgK9wTZsKPQsA27MrMsMJQRlVsMp sA== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2vxwf9nss6-23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 31 Oct 2019 09:44:04 -0700 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q080071QZTC79I0@ma1-mtap-s02.corp.apple.com>; Thu, 31 Oct 2019 09:44:01 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q0800300ZPIDJ00@nwk-mmpp-sz12.apple.com>; Thu, 31 Oct 2019 09:44:00 -0700 (PDT) X-Va-A: X-Va-T-CD: 5a4cc7aafe5ad7bd548f81852640ab7c X-Va-E-CD: ba2bffe688ebaa9295eb4635db9ccecd X-Va-R-CD: 58a98c6c9222bf6602223abf0d582acc X-Va-CD: 0 X-Va-ID: b71fec09-0c27-4e98-9c71-52c0753e6d12 X-V-A: X-V-T-CD: 14c058c52c014e00437f441b5bf37a88 X-V-E-CD: ba2bffe688ebaa9295eb4635db9ccecd X-V-R-CD: 58a98c6c9222bf6602223abf0d582acc X-V-CD: 0 X-V-ID: a02f3076-2770-46db-a559-dba7a35081e2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-31_06:,, signatures=0 Received: from [17.235.62.27] (unknown [17.235.62.27]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q0800FZOZTBDLD0@nwk-mmpp-sz12.apple.com>; Thu, 31 Oct 2019 09:44:00 -0700 (PDT) Sender: afish@apple.com From: "Andrew Fish" MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Subject: Re: [edk2-devel] Question regarding MMIO address space exposed from GetMemoryMap Date: Thu, 31 Oct 2019 09:43:59 -0700 References: To: devel@edk2.groups.io, jon@solid-run.com In-reply-to: Message-id: <40EC82CF-65F6-407D-BA67-09E284DB3EBC@apple.com> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-31_06:,, signatures=0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Jon, Its a little confusing but gBS->GetMemoryMap () only returns information a= bout DRAM and any address that requires a kernel virtual address mapping in= EFI. The OS calls EFI Runtime Services from a kernel virtual mapping so th= e memory map is also involved in the hand shake to communicate the virtual = address mappings to EFI. Thus any MMIO region in the EFI Memory Map should = always have the EFI_MEMORY_RUNTIME attribute set. The most common MMIO reg= ion to be mapped is the NOR FLASH to support the EFI Runtime Variable servi= ces.=20 On a UEFI system MMIO regions are described to the OS via ACPI. Processing= the ACPI tables requires an interpreter, and source to an interpreter is a= vailable at the ACPI CA site [1].=20 The PI (Platform Initialization) Spec has a concept called the Global Cohe= rency Domain (GCD) [2]. The GCD is the map for who owns the CPU address and= IO (x86 in/out instructions not MMIO) space. You can dump the GCD info via= gDS->GetMemorySpaceMap(). The idea is the DRAM controller would carve out = a EfiGcdMemoryTypeSystemMemory range, and the PCI Host Bridge would carve o= ut a EfiGcdMemoryTypeMemoryMappedIo range, etc.=20 Note: A UEFI implementation is not required to be constructed out of PI Sp= ec components, but the EDKII UEFI implementation is constructed using the P= I Specification.=20 [1] https://acpica.org/downloads/uefi-support [2] Sorry I could not make up a better name at the time.=20 Thanks, Andrew Fish > On Oct 31, 2019, at 1:32 AM, Jon Nettleton wrote: >=20 > I am working on sorting out a failure on test 605 of the SBSA test. > The test is "Where a memory access is to an unpopulated part of the > addressable memory space, accesses must be terminated in a manner that > is presented to the PE as either a precise Data Abort or that causes a > system error interrupt or an SPI or LPI interrupt to be delivered to > the GIC." The issue is that the random test address that was chosen > 0x04200000 falls directly in the middle of the Qoriq configuration, > control, and status register (CCSR) address space. This is an area in > the memory space that provides CPU access to the device registers. >=20 > An entry is added for this region in the VirtualMemoryMap, and > registered with the attribute, ARM_MEMORY_REGION_ATTRIBUTE_DEVICE. > However only a handful of devices are being registered so only a > couple of ranges are showing up in memmap as MMIO. >=20 > The SBSA test in question gets the memorymap and starts at the address > mentioned above and looks for the first chunk of memory that is free > and then attempts to access the memory and is looking for a Data > Abort. Of course a data abort is not generated because 0x04200000 is > a valid address. If you offset this to 0x42000000 then a DA is > generated as expected and the test passes. >=20 > There is a very old thread started by Ard, "MMIO regions in > GetMemoryMap ()", in which he questions if all the MMIO regions should > be reported by GetMemoryMap() or only the ones being used by > initialized devices, which is what the current implementation does. > The end result of the thread was the current implementation is > correct. That leaves me with the question, "What is the proper > solution for the current implementation that I am working with?" >=20 > To me it seems like I need a special Library that on boot goes through > and claims and maps every valid MMIO slot in this region, and then > have the drivers use this library for proxying requests to > gDS->AddMemorySpace (), gDS->SetMemorySpaceAttributes () etc. If > there is a standardized way to deal with this configuration I would > much rather follow that. >=20 > Thanks for any input, > Jon >=20 >=20 >=20