From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) by mx.groups.io with SMTP id smtpd.web10.1422.1572597672747177144 for ; Fri, 01 Nov 2019 01:41:13 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@solid-run-com.20150623.gappssmtp.com header.s=20150623 header.b=ifkK5vAP; spf=pass (domain: solid-run.com, ip: 209.85.166.196, mailfrom: jon@solid-run.com) Received: by mail-il1-f196.google.com with SMTP id f201so2420360ilh.6 for ; Fri, 01 Nov 2019 01:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=solid-run-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mv6SRiYkBhT9qBuLrYSSYVYggvUfMrVKxaW9qlzSwWM=; b=ifkK5vAPq6lMO5Q5gl83obybbFUUA4Me3uw+AZiwclW99eOCwQ+brDUbM0JsM3p9BP ODf65mj2E1wcyzaxrM7y6r4voDvT/v0FwaM/V4BNqGNusW/Pl8cRE6lA8wn22Dw8ZkZo xb7ZJmkP4UjCs+MKYO++QC6QwRWsrNcSifrfLfmEweAVbst0gHfPThh5OVx+gY7PLdk6 dYtv0+bqa0RprJLzlOM5+pZtDRrSpUCVbZ1facck0bRz6arUrqQK8IPAlBpoURx7uyhV 6AftnT6ahxwVVffCnbMsxxx0NJPcicxIahXjlSCDTqGweqjiQr/bDus/tW/2TK4u/leD UNew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mv6SRiYkBhT9qBuLrYSSYVYggvUfMrVKxaW9qlzSwWM=; b=BUBpdTjApRdvTeixSPgp8418gin+2kird4J5ySxzqzSKdBU/iY64yCXmaInSDzBtu+ mA4Qgz5KQx3kyLo/5vgzaIYESwyE7/1K9Yqpb/Ldj7p7Oimm2bNDIud45bAmejbjluvo DPTu45ODLQ2MokGMo2pSgIehTzT71nLgV557In6ym393RD+NO3A2PdD9ZUj8ARttSSyZ dW2CLEiT6PUbmGng2QpCEFpH2+dkNEHNCVblFfZMgx4MOPYOCQkdyCx29hDPxHti13hF +LgzxhYFeofcactMp8la2esV0VYUC1HnKtlouQvEhpWfDyVuBVVuX+Ohv4M2nuKthRwS AF0w== X-Gm-Message-State: APjAAAXtlk5n0qU0AiE1MdgrqCyBdLGetuP6kyiuq5zrDehmsNde1E4Q oJwy65PhZpxNxmVs0Uif0Jk73Wsmj8hB8TL/jhSi/g== X-Google-Smtp-Source: APXvYqxXAcUxOpgU/Xk8J2o4xpMIqaFm8l3f2sRjS1AbkbFLJx/AZFqJtUozR1WSIV+0JJrgK4P2paNNgMWX5R+jIjQ= X-Received: by 2002:a05:6e02:c2c:: with SMTP id q12mr11396186ilg.205.1572597672092; Fri, 01 Nov 2019 01:41:12 -0700 (PDT) MIME-Version: 1.0 References: <40EC82CF-65F6-407D-BA67-09E284DB3EBC@apple.com> <15D2F44E3D791472.7420@groups.io> In-Reply-To: <15D2F44E3D791472.7420@groups.io> From: "Jon Nettleton" Date: Fri, 1 Nov 2019 09:40:35 +0100 Message-ID: Subject: Re: [edk2-devel] Question regarding MMIO address space exposed from GetMemoryMap To: "Jon Nettleton via Groups.Io" Cc: "Andrew Fish via Groups.Io" , devel@edk2.groups.io Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 1, 2019 at 6:57 AM Jon Nettleton via Groups.Io wrote: > > On Thu, Oct 31, 2019 at 5:44 PM Andrew Fish via Groups.Io > wrote: > > > > Jon, > > > > Its a little confusing but gBS->GetMemoryMap () only returns informatio= n about 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= the memory map is also involved in the hand shake to communicate the virtu= al address mappings to EFI. Thus any MMIO region in the EFI Memory Map shou= ld always have the EFI_MEMORY_RUNTIME attribute set. The most common MMIO = region to be mapped is the NOR FLASH to support the EFI Runtime Variable se= rvices. > > > > On a UEFI system MMIO regions are described to the OS via ACPI. Process= ing the ACPI tables requires an interpreter, and source to an interpreter i= s available at the ACPI CA site [1]. > > > > The PI (Platform Initialization) Spec has a concept called the Global C= oherency 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 o= ut a EfiGcdMemoryTypeSystemMemory range, and the PCI Host Bridge would carv= e out a EfiGcdMemoryTypeMemoryMappedIo range, etc. > > > > Note: A UEFI implementation is not required to be constructed out of PI= Spec components, but the EDKII UEFI implementation is constructed using th= e PI Specification. > > > > [1] https://acpica.org/downloads/uefi-support > > [2] Sorry I could not make up a better name at the time. > > > > Thanks, > > > > Andrew Fish > > > > > On Oct 31, 2019, at 1:32 AM, Jon Nettleton wrote: > > > > > > 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 tha= t > > > 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 i= n > > > the memory space that provides CPU access to the device registers. > > > > > > 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. > > > > > > The SBSA test in question gets the memorymap and starts at the addres= s > > > 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. > > > > > > There is a very old thread started by Ard, "MMIO regions in > > > GetMemoryMap ()", in which he questions if all the MMIO regions shoul= d > > > 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?" > > > > > > To me it seems like I need a special Library that on boot goes throug= h > > > 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. > > > > > > Thanks for any input, > > > Jon > > > > > > > > > > > > > > > > > > > Andrew, > > Thanks for clearing this up. I definitely understand the > relationships much better now. I am still uncertain of the proper way > to fix this issue regarding the SBSA peripheral test. The test is > using gBS->GetMemoryMap in order to look for available memory > segments, which according to the earlier thread and your confirmation > "gBS->GetMemoryMap () only returns information about DRAM and any > address that requires a kernel virtual address mapping in EFI.", which > means that this test will never work on this platform because the > address that was randomly chosen just happens to fall right into the > address range for the device addresses that are valid so won't produce > a DA, but aren't being used by EFI therefore don't require a virtual > address mapping in EFI. > > Is this something I should bring up with the SBSA group? > > -Jon > I have followed up with ARM and they agree it is an issue with the test and not a configuration error. They will provide a waiver and look into refining the test in the future. Thanks for your help.