From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id AFB6B1A1DE9 for ; Tue, 13 Sep 2016 07:56:21 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id i130so36536505wmf.0 for ; Tue, 13 Sep 2016 07:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=5vu5lkLFEWIn6M4Bvky+ZJGBDY7t6oO1aSB54AekBAk=; b=Co1t6UnSxg5TQkWWSeZVUDun/ygzzSeYkPe/mBMDtf1tIUyX3jKxdoB9dhbhwsPoMz mvTQlR827ZmfRaS/tITKgWh6dYa+H7YCcXLzJTpc10gLDPaYTrHnCc0SSBinehBF1n96 eixcI8LQl0nb0M2tKkwBrBEOP5Rg9VljzBsrQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=5vu5lkLFEWIn6M4Bvky+ZJGBDY7t6oO1aSB54AekBAk=; b=fhB3Yb0CjpeuVVnRvfUMWDUDmCIk5sEQt8BMIQVLv07A75C6SKT0+0WcTNiUNCaa4f 79C3yyZLkz0//RsNsREgt8sXacjwGwe87aK/mJcPYjGHgo6UaIMZQ1TEVYbflroCDpdc 5/nDQnMrn9IsLRurUolHkDc44RxatXuU29FatI40HilO+cvhc8n6x6jp6ALnVhzBcUzo KOheLpstHe7N+jiOx5nICL9LsjhUiLsj6FQn4tNbQetydkr2ZUWjMPtb8TrocXzHcwUR uugh1YNHL2dutOu0IoDjyYdxkzpEGCV/N/KgrueO5od78SsueL7lYuTg/my6d/8w0/fW tMeA== X-Gm-Message-State: AE9vXwOh4yBVQ+86G63clr1R7mwY+Cv+tuDcEhIg9ItXf0Qne0g06eovhz8X3UdJpHRuSgzh X-Received: by 10.28.153.202 with SMTP id b193mr1234441wme.62.1473778580198; Tue, 13 Sep 2016 07:56:20 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id 123sm23333636wmj.5.2016.09.13.07.56.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Sep 2016 07:56:19 -0700 (PDT) Date: Tue, 13 Sep 2016 15:56:17 +0100 From: Leif Lindholm To: Ard Biesheuvel Cc: "Ni, Ruiyu" , Laszlo Ersek , "Yao, Jiewen" , "Zeng, Star" , "Tian, Feng" , "Gao, Liming" , "edk2-devel@lists.01.org" , Andrew Fish , "Kinney, Michael D" Message-ID: <20160913145617.GX16080@bivouac.eciton.net> References: <1473685561-1418-1-git-send-email-ard.biesheuvel@linaro.org> <74D8A39837DF1E4DA445A8C0B3885C50385FCEB6@shsmsx102.ccr.corp.intel.com> <449c21bc-ddfc-697a-bc25-7daa05485b6c@redhat.com> <734D49CCEBEEF84792F5B80ED585239D58D54EC7@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [PATCH] MdeModulePkg/PciBusDxe: make BAR degradation dependent on OPROM presence X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 14:56:22 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Adding Andrew, Mike, On Tue, Sep 13, 2016 at 08:43:39AM +0100, Ard Biesheuvel wrote: > On 13 September 2016 at 06:46, Ni, Ruiyu wrote: > >>* Another idea is to check a dynamic PCD that the platform can set. New > >>PCDs are frowned upon in MdeModulePkg however, so I don't expect this to > >>be a popular fix. > > > > I agree with you. > > The requirement of dynamic PCD actually indicates we have a > > missing interface between platform and PciBus core driver. > > I personally don't like dynamic PCD very much. It's equivalent to > > protocol. Then why should we use PCD instead of protocol? To avoid > > changing spec?? > > > > The usage of PciIncompatibleDevice protocol is the solution we came up. > > It's also the currently recommended way to solve this type of issue. > > ECR 1529 introduced in PI 1.4A was initiated by this issue. > > We are all aware that the PciIncompatibleDevice protocol can be used > to work around this. But this means that, while this issue only exists > on X64, all architectures need to install additional protocols and > rely on runtime processing to disable a feature they did not want in > the first place. Is the practice of degrading 64-bit MMIO BARs for > option ROMs even in the specs? > > So how about a PCD feature flag? Or even simply a '#ifdef MDE_CPU_X64' > around the block that degrades the 64-bit MMIO BARs if an option ROM > is detected? Ideally, we should implement PciIncompatibleDevice > protocol the other way around, and add a default implementation to > IntelFrameworkModulePkg to performs the BAR degradation on platforms > with a legacy BIOS and option ROMs Yes, the situation of requiring an implementation of PciIncompatibleDevice to support an actually compatible device, in order to not require it for actually incompatible platforms seems at the very least somewhat semantically dubious to me. By order of my preference, I would say we could: - Invert the use of PciIncompatibleDevice with a default implementation for IntelFrameworkModulePkg - #ifdef MDE_CPU_X64 - Add a dynamic Pcd - Retain the semantically incorrect use of PciIncompatibleDevice, but provide a single implementation reusable across OvmfPkg and all !X64 platforms. Regards, Leif