All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Bjorn Helgaas <helgaas@kernel.org>, linux-pci@vger.kernel.org
Cc: "Florent DELAHAYE" <kernelorg@undead.fr>,
	"Konrad J Hambrick" <kjhambrick@gmail.com>,
	"Matt Hansen" <2lprbe78@duck.com>,
	"Benoit Grégoire" <benoitg@coeus.ca>,
	"Nicholas Johnson" <nicholas.johnson-opensource@outlook.com.au>,
	"Mika Westerberg" <mika.westerberg@linux.intel.com>,
	"Werner Sembach" <wse@tuxedocomputers.com>,
	mumblingdrunkard@protonmail.com, linux-kernel@vger.kernel.org,
	"Bjorn Helgaas" <bhelgaas@google.com>
Subject: Re: [PATCH v2 0/4] PCI: Continue E820 vs host bridge window saga
Date: Thu, 8 Dec 2022 21:03:32 +0100	[thread overview]
Message-ID: <2ee3cee0-965a-a36e-da2c-d671b102c8d2@redhat.com> (raw)
In-Reply-To: <20221208190341.1560157-1-helgaas@kernel.org>

Hi,

On 12/8/22 20:03, Bjorn Helgaas wrote:
> From: Bjorn Helgaas <bhelgaas@google.com>
> 
> When allocating space for PCI BARs, Linux avoids allocating space mentioned
> in the E820 map.  This was originally done by 4dc2287c1805 ("x86: avoid
> E820 regions when allocating address space") to work around BIOS defects
> that included unusable space in host bridge _CRS.
> 
> Some recent machines use EfiMemoryMappedIO for PCI MMCONFIG and host bridge
> apertures, and bootloaders and EFI stubs convert those to E820 regions,
> which means we can't allocate space for hot-added PCI devices (often a
> dock) or for devices the BIOS didn't configure (often a touchpad)
> 
> The current strategy is to add DMI quirks that disable the E820 filtering
> on these machines and to disable it entirely starting with 2023 BIOSes:
> 
>   d341838d776a ("x86/PCI: Disable E820 reserved region clipping via quirks")
>   0ae084d5a674 ("x86/PCI: Disable E820 reserved region clipping starting in 2023")
> 
> But the quirks are problematic because it's really hard to list all the
> machines that need them.
> 
> This series is an attempt at a more generic approach.  I'm told by firmware
> folks that EfiMemoryMappedIO means "the OS should map this area so EFI
> runtime services can use it in virtual mode," but does not prevent the OS
> from using it.
> 
> The first patch removes large EfiMemoryMappedIO areas from the E820 map.
> This doesn't affect any virtual mapping of those areas (that would have to
> be done directly from the EFI memory map) but it means Linux can allocate
> space for PCI MMIO.
> 
> The rest are basically cosmetic log message changes.
> 
> Changes from v1 to v2:
> - Remove only large (>= 256KB) EfiMemoryMappedIO areas from E820 to avoid
>   the Lenovo X1 Carbon suspend/resume problems.  This machine includes
>   64KB of non-window space in the PNP0A03 _CRS, and a corresponding
>   EfiMemoryMappedIO area seems to be the only clue to avoid it (see
>   https://bugzilla.redhat.com/show_bug.cgi?id=2029207).  Interdiff below.

Thanks, v2 looks good to me:

Acked-by: Hans de Goede <hdegoede@redhat.com>

for the series.

I have also started a Fedora kernel test-build with this series added
and asked the reporters of the ideapad touchpad + x1 carbon suspend/resume:

https://bugzilla.redhat.com/show_bug.cgi?id=1868899
https://bugzilla.redhat.com/show_bug.cgi?id=2029207

bugs to test.

Regards,

Hans



> Bjorn Helgaas (4):
>   efi/x86: Remove EfiMemoryMappedIO from E820 map
>   PCI: Skip allocate_resource() if too little space available
>   x86/PCI: Tidy E820 removal messages
>   x86/PCI: Fix log message typo
> 
>  arch/x86/kernel/resource.c  |  8 +++++--
>  arch/x86/pci/acpi.c         |  2 +-
>  arch/x86/platform/efi/efi.c | 46 +++++++++++++++++++++++++++++++++++++
>  drivers/pci/bus.c           |  4 ++++
>  4 files changed, 57 insertions(+), 3 deletions(-)
> 


      parent reply	other threads:[~2022-12-08 20:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-08 19:03 [PATCH v2 0/4] PCI: Continue E820 vs host bridge window saga Bjorn Helgaas
2022-12-08 19:03 ` [PATCH v2 1/4] efi/x86: Remove EfiMemoryMappedIO from E820 map Bjorn Helgaas
2022-12-09  8:06   ` Hans de Goede
2022-12-09 11:04     ` Hans de Goede
2022-12-09 20:10       ` Bjorn Helgaas
2023-01-13 10:46   ` Baowen Zheng
2023-01-13 13:54     ` [PATCH " Bjorn Helgaas
2022-12-08 19:03 ` [PATCH v2 2/4] PCI: Skip allocate_resource() if too little space available Bjorn Helgaas
2022-12-08 19:03 ` [PATCH v2 3/4] x86/PCI: Tidy E820 removal messages Bjorn Helgaas
2022-12-09 18:42   ` Andy Shevchenko
2022-12-09 20:34     ` Bjorn Helgaas
2022-12-09 21:33       ` Andy Shevchenko
2022-12-08 19:03 ` [PATCH v2 4/4] x86/PCI: Fix log message typo Bjorn Helgaas
2022-12-09 18:43   ` Andy Shevchenko
2022-12-09 20:51     ` Bjorn Helgaas
2022-12-09 21:35       ` Andy Shevchenko
2022-12-09 21:52         ` Bjorn Helgaas
2022-12-10 20:55           ` Andy Shevchenko
2022-12-08 20:03 ` Hans de Goede [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2ee3cee0-965a-a36e-da2c-d671b102c8d2@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=2lprbe78@duck.com \
    --cc=benoitg@coeus.ca \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=kernelorg@undead.fr \
    --cc=kjhambrick@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=mumblingdrunkard@protonmail.com \
    --cc=nicholas.johnson-opensource@outlook.com.au \
    --cc=wse@tuxedocomputers.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.