From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@amazon.com header.s=amazon201209 header.b=NtI6cvVf; spf=pass (domain: amazon.com, ip: 207.171.184.25, mailfrom: prvs=074357edd=graf@amazon.com) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) by groups.io with SMTP; Thu, 27 Jun 2019 09:36:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1561653402; x=1593189402; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=QWviX/zGS28QQhCCFZ0wB2T88nbw7qofy0ZAet6usn4=; b=NtI6cvVfDl0Vs/blWeS0JJGgKTWsaf+TAUGeKdpfKCbiGdnQmbRhB2ML 4Ydqr1tCLmnlvURMFJyphPo7Zq2pFLR1f3thhfUKI9gxA6z2fbXIQQ/h2 wmlgmMKBdRfk3c6qtPp9Vhky/cX+wMnzPAlX+h/G/5uxC/SjnZcVrynBM 8=; X-IronPort-AV: E=Sophos;i="5.62,424,1554768000"; d="scan'208";a="813126148" Received: from sea3-co-svc-lb6-vlan2.sea.amazon.com (HELO email-inbound-relay-2c-2225282c.us-west-2.amazon.com) ([10.47.22.34]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 27 Jun 2019 16:36:32 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2c-2225282c.us-west-2.amazon.com (Postfix) with ESMTPS id C02D8A1D6B; Thu, 27 Jun 2019 16:36:32 +0000 (UTC) Received: from EX13D20UWC001.ant.amazon.com (10.43.162.244) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 27 Jun 2019 16:36:32 +0000 Received: from 38f9d3867b82.ant.amazon.com (10.43.161.147) by EX13D20UWC001.ant.amazon.com (10.43.162.244) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 27 Jun 2019 16:36:30 +0000 To: CC: , David Woodhouse , "Ard Biesheuvel" From: graf@amazon.com Subject: Re: [PATCH v3 4/4] OvmfPkg: don't assign PCI BARs above 4GiB when CSM enabled Message-ID: <91d912c9-533a-22a3-4aa3-0fe114e1149f@amazon.com> Date: Thu, 27 Jun 2019 18:36:28 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 X-Originating-IP: [10.43.161.147] X-ClientProxiedBy: EX13D27UWA002.ant.amazon.com (10.43.160.30) To EX13D20UWC001.ant.amazon.com (10.43.162.244) Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Hi David and Laszlo, (with broken threading because gmane still mirrors the old ML ...) > Mostly, this is only necessary for devices that the CSM might have > native support for, such as VirtIO and NVMe; PciBusDxe will already > degrade devices to 32-bit if they have an OpROM. > > However, there doesn't seem to be a generic way of requesting PciBusDxe > to downgrade specific devices. > > There's IncompatiblePciDeviceSupportProtocol but that doesn't provide > the PCI class information or a handle to the device itself, so there's > no simple way to just match on all NVMe devices, for example. > > Just leave gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size set to zero for > CSM builds, until/unless that can be fixed. > > Signed-off-by: David Woodhouse > Reviewed-by: Laszlo Ersek > --- > OvmfPkg/OvmfPkgIa32X64.dsc | 4 ++++ > OvmfPkg/OvmfPkgX64.dsc | 4 ++++ > 2 files changed, 8 insertions(+) > > diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc > index 639e33cb285f..ad20531ceb8b 100644 > --- a/OvmfPkg/OvmfPkgIa32X64.dsc > +++ b/OvmfPkg/OvmfPkgIa32X64.dsc > @@ -543,7 +543,11 @@ [PcdsDynamicDefault] > gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Base|0x0 > gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size|0x0 > gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0 > +!ifdef $(CSM_ENABLE) > + gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x0 > +!else > gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x800000000 > +!endif > > gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0 > > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc > index 69a3497c2c9e..0542ac2235b4 100644 > --- a/OvmfPkg/OvmfPkgX64.dsc > +++ b/OvmfPkg/OvmfPkgX64.dsc > @@ -542,7 +542,11 @@ [PcdsDynamicDefault] > gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Base|0x0 > gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size|0x0 > gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0 > +!ifdef $(CSM_ENABLE) > + gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x0 IIRC x86 Linux just takes firmware provided BAR maps as they are and doesn't map on its own. Or does it map if a BAR was previously unmapped? In the former case, wouldn't that mean that we're breaking GPU passthrough (*big* BARs) for OVMF if the OVMF version happens to support CSM? So if a distro decides to turn on CSM, that would be a very subtle regression. Would it be possible to change the PCI mapping logic to just simply *prefer* low BAR space if there's some available and the BAR is not big (<64MB for example)? That way we could have CSM enabled OVMF for everyone ;) Alex > +!else > gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x800000000 > +!endif > > gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0 > > -- > 2.21.0