From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 4A22C1A1E26 for ; Tue, 13 Sep 2016 00:43:40 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id m11so368540682oif.1 for ; Tue, 13 Sep 2016 00:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WUKqDSWWPrsAw4d2vv1oWCs2Kmw/hBmYk14B/CdbdQ8=; b=OX9cGhnoNmM+uECIx9ICAFv8/xCny9aLCdiFyikncbcMIKim5rP9LKpX4I/zk5Gac1 YTIvWo5qmRKiWRVQ0rIFkLzxRxvvDRqs7WxIDNmmu+D2q4EscSPN8kmEgnLZRB/9jTsM XicvWzwhjpKYHpIdDcSx9d9rP3oVySswxWGi0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WUKqDSWWPrsAw4d2vv1oWCs2Kmw/hBmYk14B/CdbdQ8=; b=Y/9c5gwirHcDhNzERSnELix/JVz0uh8C425yAEc5mdljgnCBpW2o4XLRbe1akTBJmF CrABczw18P3Lw+cvKGxkjzE3T7pmRiuyVXOes9GIgMGSpunRq4cJ0jGPfYaGusTrj3Ck SzVqpTHhCa+Abk17xg2vgj9qOIQ7XXz6eNqBU+FyNvBcn3jQ3L1K58AFAX6wbgJ9qNQx P2MAhu/VDVTyJiYV56rzUr0NR+pte2xWq8V/qIt7FxikJnzNjUf+LjkAZpwiBnCmumrn r71BipPj/fqjsxDYJ8q8zrVwlIcdfOPIybzmnW0mkkTT67ZymG4bBX3Ygb4Uxdqazo7v VCXw== X-Gm-Message-State: AE9vXwMRkX5OJDQlVJaQMJOG4FlsdjG/rbbrU58TODIWsh57B9Efq7HVqKb2BZNIelAns+ssGRPGlb+g6fTd0fk+ X-Received: by 10.202.205.70 with SMTP id d67mr4954821oig.170.1473752619512; Tue, 13 Sep 2016 00:43:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Tue, 13 Sep 2016 00:43:39 -0700 (PDT) In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D58D54EC7@SHSMSX103.ccr.corp.intel.com> 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> From: Ard Biesheuvel Date: Tue, 13 Sep 2016 08:43:39 +0100 Message-ID: To: "Ni, Ruiyu" Cc: Laszlo Ersek , "Yao, Jiewen" , "Zeng, Star" , "Tian, Feng" , "Gao, Liming" , "edk2-devel@lists.01.org" , "leif.lindholm@linaro.org" 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 07:43:40 -0000 Content-Type: text/plain; charset=UTF-8 On 13 September 2016 at 06:46, Ni, Ruiyu wrote: > > > Regards, > Ray > >>-----Original Message----- >>From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek >>Sent: Monday, September 12, 2016 9:49 PM >>To: Ard Biesheuvel ; Yao, Jiewen >>Cc: Ni, Ruiyu ; Tian, Feng ; edk2-devel@lists.01.org ; >>leif.lindholm@linaro.org; Gao, Liming ; Zeng, Star >>Subject: Re: [edk2] [PATCH] MdeModulePkg/PciBusDxe: make BAR degradation dependent on OPROM presence >> >>On 09/12/16 15:16, Ard Biesheuvel wrote: >>> On 12 September 2016 at 14:15, Yao, Jiewen wrote: >>>> HI Ard >>>> We should not let MdeModulePkg depend on IntelFrameworkPkg. >>>> You patch violates the dependency rule. >>>> I suggest we figure out other solution to resolve the problem. >>>> >>> >>> Yes, please. And please keep us informed about any solutions you come up with. >> >>* One idea is to parse the PCI expansion ROM in order to see what image >>types are contained within. If there is no (Code type == 0x00) image in >>the oprom, then the oprom is useless for legacy boot anyway, so it >>shouldn't trigger degradation. >> >>Unfortunately, this wouldn't help a lot in practice, since it's surely >>going to be years before hw vendors migrate to pure UEFI oproms on their >>graphics and network cards. :( > Yes the first idea doesn't work because it cannot solve all the problems: some > cards may still contain legacy option ROM. The resource degrade happens > before PciBus knows which option rom to run by platform. And we even met case > the card only contains legacy option rom but platform just don't want to dispatch > the legacy rom. > >>* 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 -- Ard.