From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Thu, 20 Jun 2019 05:58:04 -0700 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3E3B530BB551; Thu, 20 Jun 2019 12:57:58 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-226.ams2.redhat.com [10.36.117.226]) by smtp.corp.redhat.com (Postfix) with ESMTP id D292660FAB; Thu, 20 Jun 2019 12:57:53 +0000 (UTC) Subject: Re: [edk2] [PATCH] OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM To: David Woodhouse Cc: "devel@edk2.groups.io" , Ray Ni , Jordan Justen , Ard Biesheuvel References: <1463609573-16626-1-git-send-email-lersek@redhat.com> <9c690717587ff1ccd9a8ec8bd3d741e6c86f8bb3.camel@infradead.org> <01a87fee-5a17-d027-39fd-2a2e0a36787b@redhat.com> From: "Laszlo Ersek" Message-ID: <28b2a68d-ad2f-1137-d356-227ee43db295@redhat.com> Date: Thu, 20 Jun 2019 14:57:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Thu, 20 Jun 2019 12:57:58 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit (updating Ray's email) On 06/20/19 00:19, David Woodhouse wrote: > >> the driver is thoroughly commented. See especially the >> DriverInitialize() function. Can you determine which one(s) of those >> statements doesn't / don't hold any longer? >> >> Or maybe IncompatiblePciDeviceSupportDxe works as before, but commit >> 065ae7d717f9 ("MdeModulePkg/PciBusDxe: make OPROM BAR degradation >> configurable", 2016-09-26) made a difference? (Adding Ard.) >> >> I'm just guessing of course; a bisection could prove more effective. > > I think I worked it out. The problem is that the nvme controller doesn't > have a ROM so it wasn't triggering the downgrade to 32-bit in the first > place. > > By hacking IncompatiblePciDeviceSupportDxe to always return configuration > with 32+bit "granularity" I can boot. That does it for *all* devices, of > course... but I don't get the PCI class; only device/vendor IDs. Doesn't this imply that we have a more generic problem in PciBusDxe? AIUI, the current aperture degradation (for BAR allocation purposes) is meant to allow the device's own (specific) legacy option ROM to access the BARs. If the device has no option ROM, this particular goal falls away. (And OVMF's driver basically implements an override, in case the oprom does exist, but "legacy" is whole-sale unsupported by the platform.) If the generic (device independent) CSM code -- *any* generic CSM in fact -- is expected to access BARs, then the logic in PciBusDxe is both too lax and too restrictive at the same time. It's too lax due to factors discussed previously (see the paragraph above, and commit 065ae7d717f9), and too restrictive because it misses the "CSM per se needs BAR access" case. For working this around in OVMF, we'd have to change the OVMF driver's behavior from "force 64-bit, or keep silent", to "force 64-bit, or force 32-bit". This looks like a kludge that entirely supplants the PciBusDxe logic. So I'm not a fan of it. That said, if you can patch IncompatiblePciDeviceSupportDxe such that the change only affect the CSM_ENABLE build of OVMF observably, I guess I can live with it. Thanks Laszlo