Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp2126890pxb; Wed, 9 Feb 2022 11:23:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJyKwPJVWb95GiAGEY3y1wmkMD5r4Tup5QUcC1okZuEkVKeIioj1n5QS88veYM4xnizn+j+3 X-Received: by 2002:a05:6a00:1652:: with SMTP id m18mr3858864pfc.56.1644434639203; Wed, 09 Feb 2022 11:23:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644434639; cv=none; d=google.com; s=arc-20160816; b=Bbopf6pCMI8aiZE/IO32Yg3qxmUQcge2eiXf2L249bc23kqeJvJXWT9PwUgA/WvxHd 4miVP7jHh06SD4RBsrITyEKockJuEdOthuouLb2/BXbpCUbl7UywmrVfqy/PDpJmfyuC 76biG+HM9uiGcjoQs/hm5hYVKMrE2In1gxz5GS43G9ELtkQAkGAnayrmxVDR0ibMQ4D0 SC4hRLgeelaz89LrDEvXzrlg9kHyNeoDuvrLuEn1rLZgKlhSjiYpVeq8LMc4cHYwokd0 Q+4aOAQnkFUHnJKH00rwBu+5Bqj3IfiN7e/NlukaroCvKkgRhFfVfSrK+ylynohTYodW YdAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=jXZVkLLgFeJwiCRsj2TzmZOaPRtKXCUinC7JnrHv210=; b=zo76Ps+Gp1aLkrZ4nFC3XESWpJJ/Ek5rq8tNCLjX4OFYj3m02E1VttULWvJ/4QVDnt 7UuFoqGuKWf3X/DTmeQ4Yf0Dc+UOAn9ktIB6MLUYuOz8tJVq7a792CZZjMk1ktUU8YOO ec4zFwNR8sz0iOF1esZH8BK/q75O5Ot6mHtbtqOsM0fB7y7trjTbsz7XBf7Pm6Pm1k9O 9+XWFlIvkz4lW9NN4RrbZI4C5nt4re+mp7h8f44dzp+zTqhHodBNK7qAyIG/IWoJPW6m IwgfpcweGgmBq6S0wBbOoU3VMfDbD370ussosF18e8neKT5tUS7qgk9A+OZli7zKohEq EEsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=TTwcDJl8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id 32si186033pgq.498.2022.02.09.11.23.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 11:23:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=TTwcDJl8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C2226C102FE0; Wed, 9 Feb 2022 11:18:28 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236486AbiBIQDo (ORCPT + 99 others); Wed, 9 Feb 2022 11:03:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236473AbiBIQDn (ORCPT ); Wed, 9 Feb 2022 11:03:43 -0500 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AFA62C0612BE; Wed, 9 Feb 2022 08:03:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644422625; x=1675958625; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=aafKnGCoEaqvsnU9LCDeEaZ8jYeHAC9CSnldTj89q44=; b=TTwcDJl80fT72VCLGnDEo8wnr2JH3WUpwCtWc0c0hLyxN1GndEZrDkIR 6D7IvWELbhJrVR2BC5+15yzisOeTyxw4De4XCe9osfOgbNQ0/mXnRrIeI +RO9IyvAkym489zfhC+kkW2IF/F3ZHBUth72zg/h4PbniyTKATjmR+ODI 1X39HaK1MXUdF40XX8yTRnPe/wNMeXAJa4Dri07vaFKIfLD4SYDuNXF61 YIIdbrwaT2GU4FMNLU9WMsf1/os8UFpW0qbFFWJ6Ma+zfI79X3HSTO+FR xEh+/8Robkh+ry/YOt3+pX/88ykN4VSOb1xaq/jM2wftajztKCg1b1hQd Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10252"; a="229205198" X-IronPort-AV: E=Sophos;i="5.88,356,1635231600"; d="scan'208";a="229205198" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2022 08:03:25 -0800 X-IronPort-AV: E=Sophos;i="5.88,356,1635231600"; d="scan'208";a="622317188" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.162]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2022 08:03:21 -0800 Received: by lahna (sSMTP sendmail emulation); Wed, 09 Feb 2022 18:01:07 +0200 Date: Wed, 9 Feb 2022 18:01:07 +0200 From: Mika Westerberg To: Hans de Goede Cc: "Rafael J. Wysocki" , Bjorn Helgaas , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Myron Stowe , Juha-Pekka Heikkila , Ingo Molnar , Borislav Petkov , linux-acpi , Linux PCI , x86@kernel.org, Linux Kernel Mailing List , Benoit =?iso-8859-1?Q?Gr=E9goire?= , Hui Wang Subject: Re: [5.17 regression] "x86/PCI: Ignore E820 reservations for bridge windows on newer systems" breaks suspend/resume Message-ID: References: <697aaf96-ec60-4e11-b011-0e4151e714d7@redhat.com> <02994528-aaad-5259-1774-19aeacdd18fc@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02994528-aaad-5259-1774-19aeacdd18fc@redhat.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Hans, Thanks for looking into this! On Wed, Feb 09, 2022 at 04:12:32PM +0100, Hans de Goede wrote: > An alternative, much more elaborate fix would be to: > > 1. Add E820_TYPE_MMIO and E820_TYPE_MMIO_PCI_BRIDGE_WINDOW types to > enum e820_type and modify the 2 places which check for type == reserved > to treat these both as reserved too, so as to not have any functional > changes there > > 2. Modify the code building e820 tables from the EFI memmap to use > E820_TYPE_MMIO for MMIO EFI memmap entries and make e820_nomerge() > treat E820_TYPE_MMIO as non mergable to retain these as is > > 3. Modify pci_acpi_root_prepare_resources() to compare ACPI provided > bridge mmio windows against E820_TYPE_MMIO e820_Table entries and > if there is an exact match (as is the case on the Yoga C940) > then change the e820 type to E820_TYPE_MMIO_PCI_BRIDGE_WINDOW > > This means that we are now very narrowly treating EFI MMIO marked > regions special, in the special case where they are a 1:1 map > to an ACPI PCI bridge window resource. > > Note since we treat both E820_TYPE_MMIO and E820_TYPE_MMIO_PCI_BRIDGE_WINDOW > identical to the old RESERVED everywhere there is no functional change > here. > > 4. Modify arch/x86/kernel/resource.c: remove_e820_regions() to skip > e820 table entries with a type of E820_TYPE_MMIO_PCI_BRIDGE_WINDOW, > this would actually be a functional change and should fix the > issues we are trying to fix. > > Note an alternative would be to skip having the extra E820_TYPE_MMIO_PCI_BRIDGE_WINDOW > type and to skip step 3. above. That would boil down to doing the same > as your original patch in a somewhat cleaner manner. I agree and my vote goes for this last alternative (e.g skipping step 3). That would also make it slightly easier to follow the logic if someone in the future needs to investigate possible issues around this, I think.