Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp2289993pxb; Wed, 9 Feb 2022 15:17:36 -0800 (PST) X-Google-Smtp-Source: ABdhPJxk6vxePFcJ7GKFVRhjgB6Anfr+twYZrOfqHxtMzjNEHfbEtv970KMcTo0/3E5aliiYKRC/ X-Received: by 2002:a63:9812:: with SMTP id q18mr3754737pgd.446.1644448656300; Wed, 09 Feb 2022 15:17:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644448656; cv=none; d=google.com; s=arc-20160816; b=Q0+/Vs+NVjzhK5zltCDCp+eHiTCgNTTxPuqQJlElZjsPSDslnApYBipptzxoLDoUw5 7ieMvSV1PhSkGzPxXePJj8LsEx6exsVp5PTbR0mFuNCPpyACYOW5Q6FtExs6wquy7nep GknxlZGtj2+YQZvQjFoDqMCLNlxy6fsqx7etVtgB2l5t6cqQjuIovyULDUEMqyiWPgtV BiV9IblR5XLWXhiZL3IVvMzkjAYygfY8eD6E3afHN6yRv3R4CMV9xP+CuioQlLqV7sCZ jeW+q/VT6rW6ofQc8c2iLQJi1yO3jIs1wwR/yNbPui1eOrkbe6ANZD/SqM2hdB74SJww /dzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :message-id:subject:cc:to:from:date:dkim-signature; bh=sVwTdrdu+iqIIFgaDPuxTCezF3c67RJHBYVmHelGhO8=; b=pUKOPVbNrvniRNPiCttxUjpkfooPzXJNCCc5z+bFOaR+a/u1HX14lWubVLlMsCtWKj CmHxgvp3t7XXGXYdwRScLzaYTGt/vDPWwVDcqepu5gQ0oKrB4aUBqmfMzDdKoJ2/C+0C OBuUAxYgiV6DAHoLdnAdJmhLVDgwlKyExlescElHfH1wR5Kn2gkNBgBwX9Nmiilus9XR wFzw/7Qvp5XLMeUDtc8cUJSjr3wa3wMuBejZpRw8F+vBcfB0i/6bpJhJ2U6jlsK7szJG FSJ9AG38JKNQ6Pu5UavJoTaGAoATkxpqTXELVoUTDVEceuvfArqQmi53AkeFjMo+Se7C R0MQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=JUwNLoEq; 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=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id b4si281566plz.351.2022.02.09.15.17.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 15:17:36 -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=@kernel.org header.s=k20201202 header.b=JUwNLoEq; 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=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 1B5C2E051114; Wed, 9 Feb 2022 15:15:41 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233570AbiBIVgs (ORCPT + 99 others); Wed, 9 Feb 2022 16:36:48 -0500 Received: from gmail-smtp-in.l.google.com ([23.128.96.19]:45282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233507AbiBIVgm (ORCPT ); Wed, 9 Feb 2022 16:36:42 -0500 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3DD55C102FD8; Wed, 9 Feb 2022 13:36:44 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id A9CE1CE2299; Wed, 9 Feb 2022 21:36:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 21F57C340E7; Wed, 9 Feb 2022 21:36:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1644442600; bh=eNht/WhgzI8HFTOVd2yW6iJsHrqt1HK/5VYfUBwQ1uM=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=JUwNLoEq61UWVbFsZ2V+yv+PvSSsVPz5tNr5QxdlYhj22VaLg9iAVui4YIh8tapzj iLN54K9XL2kynxSnFzf0FOkYC9ggxOw+OeE/RiAn5kXrCmEx1QU5iP8rBtFvhd7YDO i8AGWJv5HGyHDgCLutrG1D9MHBCO+Nbj8iDk6PXaRu5VjiUlD5B6STNGV0mHSL2U23 3m1NvYk567QRt4Blysx3IKfXJlEnX9xMoc9zUNdoBIsIjg8Ahgdd4izuV64XPVXR9x BitoHIZmPT6A+wGbRUhZx4xUGgp7vY5JAJAspX+GK4xBdWRsovJ4sP+JFUahq2gjWt Yz8czzi7mY4tA== Date: Wed, 9 Feb 2022 15:36:38 -0600 From: Bjorn Helgaas To: "Rafael J. Wysocki" Cc: Keith Busch , Kai-Heng Feng , Bjorn Helgaas , Linux PM , Nirmal Patel , Jonathan Derrick , Lorenzo Pieralisi , Rob Herring , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Linux PCI , Linux Kernel Mailing List Subject: Re: [PATCH v3] PCI: vmd: Honor ACPI _OSC on PCIe features Message-ID: <20220209213638.GA587920@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 On Tue, Dec 07, 2021 at 02:15:04PM +0100, Rafael J. Wysocki wrote: > On Tue, Dec 7, 2021 at 12:12 AM Keith Busch wrote: > > On Fri, Dec 03, 2021 at 11:15:41AM +0800, Kai-Heng Feng wrote: > > > When Samsung PCIe Gen4 NVMe is connected to Intel ADL VMD, the > > > combination causes AER message flood and drags the system performance > > > down. > > > > > > The issue doesn't happen when VMD mode is disabled in BIOS, since AER > > > isn't enabled by acpi_pci_root_create() . When VMD mode is enabled, AER > > > is enabled regardless of _OSC: > > > [ 0.410076] acpi PNP0A08:00: _OSC: platform does not support [AER] > > > ... > > > [ 1.486704] pcieport 10000:e0:06.0: AER: enabled with IRQ 146 > > > > > > Since VMD is an aperture to regular PCIe root ports, honor ACPI _OSC to > > > disable PCIe features accordingly to resolve the issue. > > > > At least for some versions of this hardare, I recall ACPI is unaware of > > any devices in the VMD domain; the platform can not see past the VMD > > endpoint, so I throught the driver was supposed to always let the VMD > > domain use OS native support regardless of the parent's ACPI _OSC. > > This is orthogonal to whether or not ACPI is aware of the VMD domain > or the devices in it. > > If the platform firmware does not allow the OS to control specific > PCIe features at the physical host bridge level, that extends to the > VMD "bus", because it is just a way to expose a hidden part of the > PCIe hierarchy. I don't understand what's going on here. Do we understand the AER message flood? Are we just papering over it by disabling AER? If an error occurs below a VMD, who notices and reports it? If we disable native AER below VMD because of _OSC, as this patch does, I guess we're assuming the platform will handle AER events below VMD. Is that really true? Does the platform know how to find AER log registers of devices below VMD? > The platform firmware does that through ACPI _OSC under the host > bridge device (not under the VMD device) which it is very well aware > of.