Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 5 Jan 2023 11:51:05 -0600
From:   Bjorn Helgaas <helgaas@kernel.org>
To:     Tony Luck <tony.luck@intel.com>
Cc:     "Liang, Kan" <kan.liang@linux.intel.com>, bhelgaas@google.com,
        hdegoede@redhat.com, kernelorg@undead.fr, kjhambrick@gmail.com,
        2lprbe78@duck.com, nicholas.johnson-opensource@outlook.com.au,
        benoitg@coeus.ca, mika.westerberg@linux.intel.com,
        wse@tuxedocomputers.com, mumblingdrunkard@protonmail.com,
        linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
        david.e.box@intel.com, yunying.sun@intel.com
Subject: Re: Bug report: the extended PCI config space is missed with 6.2-rc2
Message-ID: <20230105175105.GA1155450@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y7cL8pIqLrwv2z7+@agluck-desk3.sc.intel.com>
Precedence: bulk

On Thu, Jan 05, 2023 at 09:42:10AM -0800, Tony Luck wrote:
> On Wed, Jan 04, 2023 at 09:45:11AM -0600, Bjorn Helgaas wrote:
> > My understanding is that EfiMemoryMappedIO tells the OS to map the
> > area for use by runtime services, but is not intended to prevent the
> > OS from using the area.  Some platforms use EfiMemoryMappedIO for PCI
> > host bridge apertures, and of course the OS needs to use those.
> > 
> > If your firmware folks disagree and think Linux should be able to
> > figure this out differently, I would love to have a conversation about
> > how to do this.
> 
> It seems that 07eab0901ede ("efi/x86: Remove EfiMemoryMappedIO from E820 map")
> is also the cause of breakage for drivers/edac/sb_edac.c. It is broken
> in v6.2-rc2 and reverting this commit makes it work again.
> 
> This ancient driver probably plays fast and loose with how it ought to
> access extended PCIe config space ... but it needs to do this to read various
> memory controller configuration registers to do address translation from
> a system physical address to a DIMM address.

Hi Tony, can you share a dmesg log?  Does it look like the same thing
Kan reported, where the ECAM space is reported only via an
EfiMemoryMappedIO region and is not otherwise reserved by firmware?

Bjorn