From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41])
 by mx.groups.io with SMTP id smtpd.web12.3213.1572510797807724085
 for <devel@edk2.groups.io>;
 Thu, 31 Oct 2019 01:33:18 -0700
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@solid-run-com.20150623.gappssmtp.com header.s=20150623 header.b=tYFNEpoZ;
 spf=pass (domain: solid-run.com, ip: 209.85.166.41, mailfrom: jon@solid-run.com)
Received: by mail-io1-f41.google.com with SMTP id q1so5779866ion.1
        for <devel@edk2.groups.io>; Thu, 31 Oct 2019 01:33:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=solid-run-com.20150623.gappssmtp.com; s=20150623;
        h=mime-version:from:date:message-id:subject:to;
        bh=WKXAv9p00Sz/SKGrCrB8C4vvUhdUlIGGBIXu6Ly5wd8=;
        b=tYFNEpoZOfmP/V9tCdz/KHlUeUChV43MNNL4kyRLLbg+VCGXs7Egf5mYKWA64Yxxd7
         DmoTBXW3sjf/fPYKmEIj4iWAHnfXHWezqwCe4jsL0DS/DR4FTOu/xfrvrgYOJCDNltnm
         Na+Dx5NWg3TlM0vfwGG1aq07SnBcUHpeRWLu/zTv9szQVNX+Q9p4d1QQg3Je8VKCbpaH
         uUo5SKwucSauDqZMrs+4Z8iAsVI7yRIG9pfs7pDR/vgB24R/onGcrZ0KNLB15tfitW/j
         EYNKq8HIEWbkcnFST/o+lcwB5lrHQk/k+IUEanEWGu8zf/b6inYbj/MibHqp1dAGDP7y
         gcTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
        bh=WKXAv9p00Sz/SKGrCrB8C4vvUhdUlIGGBIXu6Ly5wd8=;
        b=iz1Zmqu36h6kvPjypfcxBsIGX5Cy7MxiLtV6nmXGGteKhcMvfv54dibk5P5FLkswXw
         nP3kw0qsm3/RBCZwQ1J5Hu/1Sefo+KxgZHNkeFcJsdspNUZYkESCjj6NAwa9ki3mdEx1
         XbnlTZ+gsmfEkF92+xcPeTZbmSpmOMW5jRf4DKTxVeZQ+CGFcd0LwWx/RqRPOkVfeVyb
         uGIM1CAGJUodtdPdtuHtWSKjixQubb3Zi6MgJWZhfeRvK0XvFghtNZzYjRk/FCbsgIy3
         Ox8WUeJqDp0GOpgWNwZwHxIgoyWK+19n+5PfVgSpoqYdKBuDRv2STLHOFM8rclP53YFQ
         nMVg==
X-Gm-Message-State: APjAAAWLMkmJ/0DN6UFonLM9tq1b9bWhvec3NtGWdbhOLLuMst0s79Ad
	lkwF6O0tTzBqunmt6Mk8/XmzMXbJggiJi7dL6O6IsW9NnxQ=
X-Google-Smtp-Source: APXvYqwtv++0POBlqjayVABono6X7H0xMA+45HyKM0HiAJWpaNSiVoJTg9W97TdNJSLBfRDK2rY7JwjGL1MdR8mI57M=
X-Received: by 2002:a02:3809:: with SMTP id b9mr2471222jaa.142.1572510796928;
 Thu, 31 Oct 2019 01:33:16 -0700 (PDT)
MIME-Version: 1.0
From: jon@solid-run.com
Date: Thu, 31 Oct 2019 09:32:40 +0100
Message-ID: <CABdtJHv09tLVz_krQRthhOjw4eL3zKtqBWPbCmSKNnRABC-EoQ@mail.gmail.com>
Subject: Question regarding MMIO address space exposed from GetMemoryMap
To: devel@edk2.groups.io
Content-Type: text/plain; charset="UTF-8"

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.

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 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.

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?"

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.

Thanks for any input,
Jon