From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2DACBC31E4B for ; Fri, 14 Jun 2019 13:10:08 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C235D20850 for ; Fri, 14 Jun 2019 13:10:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ijcRQfDw"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="sDo8l+VC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C235D20850 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=C66dw4SOabjWc77ZjKPmbushm1HAEH3KOLwP5lfFLZY=; b=ijcRQfDw/5a/BZ cuvcuJBpmMfxXs+9OFsuhZi9+QqWDE9xKmprLaGW36upijyge88qRxEc3r4bLMYUQIulhWhmyq63v n8/xHMEymvkCCivynPrAi/up83A7ZA8mGvc9y9duF2NQCcRBIqM3eVyr+iC12waLMKSSwzZFfqN6T vqMU4WpRLkobgWzqOjpmuakwupkkZWexcqhHxpXupCya68pQiErmsgSZz4PMcQj21ugeqn1J5w4Ea k/4PwxxoQIqPzAol/XGP8kdQv0uxUIqFkU9ERBsSH2qHxRoILTGxgAflSFPzYdQligNhxG315ydz4 iJldLFh7dXOI7XrqB1Lw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hblxu-0002Be-0v; Fri, 14 Jun 2019 13:09:58 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hblxr-0002B4-3Y for linux-arm-kernel@lists.infradead.org; Fri, 14 Jun 2019 13:09:56 +0000 Received: from localhost (173-25-83-245.client.mchsi.com [173.25.83.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 226DA20850; Fri, 14 Jun 2019 13:09:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1560517793; bh=mRmGyxYQIkQ13DLqdtwewdMiIqXGLpO2s27nnAvEusc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sDo8l+VCaLY0E2B0VcPOXJD86BMdLEtB6UFDeuGir9oVeofgXDhiiPtktK4q2ik2R R0MFFQ1HdF7sQmeP58ldE+asbCA3VnsDXDDCM0HuKuvUPj5H4SxLsetcui8lh3/Fw0 TL/3RAWfIln0isDW92XF/+iA1mvmZL2GaHu7I6mA= Date: Fri, 14 Jun 2019 08:09:52 -0500 From: Bjorn Helgaas To: Benjamin Herrenschmidt Subject: Re: [RFC PATCH v2] arm64: acpi/pci: invoke _DSM whether to preserve firmware PCI setup Message-ID: <20190614130952.GQ13533@google.com> References: <5783e36561bb77a1deb6ba67e5a9824488cc69c6.camel@kernel.crashing.org> <20190613190248.GH13533@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190614_060955_187121_FC62F13D X-CRM114-Status: GOOD ( 11.21 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-pci , Lorenzo Pieralisi , Sinan Kaya , linux-arm-kernel , Ard Biesheuvel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jun 14, 2019 at 06:36:32PM +1000, Benjamin Herrenschmidt wrote: > Linux can't change the switch configuration. I may have mentioned > earlier it has to do with platform sec policies. But that's not totally > relevant, we shoudn't be changing resources anyway since in theory > runtime FW might rely on where some system devices were assigned at > boot. EFI fb is another example of that. "We shouldn't be changing resources anyway" is not really useful guidance. I completely agree that we shouldn't change things *unnecessarily*, but it's up to the OS to define what makes it necessary -- it might be for rebalancing for hotplug, to make space for SR-IOV, to respect user requests to increase alignment, etc. IMO the real value of _DSM #5 is as a mechanism to advertise dependencies runtime firmware has on devices, e.g., SMM firmware might want to log errors to a PCI remote management device. If the OS moved that managment device, the SMM logging would itself cause errors. > The biggest issue for me right now is that the spec says pretty much at > _DSM #5 = 0 is equivalent to _DSM #5 absent, and Bjorn seems keen on > having it this way, but for arm64, we specifically want to distinguish > those 2 cases. Nope, my opinion is exactly the opposite. Sorry that I'm not communicating this clearly. It's true that the r3.2 spec *does* say _DSM #5 = 0 is equivalent to the situation where it's absent, but that's based on the assumption that the OS is never allowed to change PCI configuration. I think that assumption is complete nonsense and should be disregarded. _DSM #5 = 0: OS must preserve this device's BARs (current spec says "OS must not ignore") _DSM #5 = 1: OS *may* change this device's BARs (current spec says "OS may ignore") Other than _DSM #5, there's no spec I'm aware of that restricts the OS's ability to change BARs. Therefore I think "_DSM #5 = 1" is equivalent to _DSM #5 being absent, and in both cases the OS is free to change BARs as it sees fit. > Looking at the spec (and followup discussions for specs updates), I'm > quite keen on treating _DSM #5 = 1 as "wipe out the resource for that > endpoint/bridge and realloc something better. There are reasons for > that, but we can probably discuss that later. I disagree on the "wipe out all resources" part of this because we have no idea how to realloc something better. We should of course look for problems (overlapping devices, etc) and fix them. But starting from scratch and reallocating won't reliably produce anything different from the original, supposedly broken, configuration. Bjorn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel