From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web11.414.1665179396536778553 for ; Fri, 07 Oct 2022 14:49:56 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=T83mPb6/; spf=pass (domain: kernel.org, ip: 145.40.68.75, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id A2BFBB8075B for ; Fri, 7 Oct 2022 21:49:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66878C4347C for ; Fri, 7 Oct 2022 21:49:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1665179393; bh=IhsDyCp10lzX1XbUtpSgDfpOFZ5OBP63nmKPXKXr1SU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=T83mPb6/og0yOKRxBxKe8/WNWvQnzUdHyKDwQXzqwaqE+4tH4cf0ZM8OWhzjwSk6Z hvuB7Tl+0rVVmG6xZZdXdlGISs+VtrWwCQUhErZoFYscxLDhX+5j1ZcDYUc5DjE88Z RLpFWwa+M3oemMx3e95NKJTOPAfOb010bXolni9AmeVsJ96LqRbtlE+shVwkDTwj3Q R/vJgaHzIrxh3GvWVOxXBc77DDLOsVGBhseYsrSoB+5rEsk0uerYPvp0AlLi8Px9Cb h/9fUNpbWBLMrVF2dpGK101tGXdWc7jRQq1MIJskavnHJHK/GajuLd40r/xschnweX 1yBbXIESoZg7g== Received: by mail-lf1-f42.google.com with SMTP id g1so9008883lfu.12 for ; Fri, 07 Oct 2022 14:49:53 -0700 (PDT) X-Gm-Message-State: ACrzQf2hI7+yIt00FXfGRENw8G/5XjbAcVIRfpoQjDzGl1fmYm1GAkxz +2dWL82SgJLeZ5DMUllmuCKN/Fx5dRDnDpfmNYA= X-Google-Smtp-Source: AMsMyM7zaBbfcGM18JbwGKu4Sl2yOswLnsHLTrbHsCQP5ovjEV4NrkjceWgD//MuKwyfte6AzCo6FyqFrOZAmKuXhl4= X-Received: by 2002:a05:6512:150e:b0:492:d9fd:9bdf with SMTP id bq14-20020a056512150e00b00492d9fd9bdfmr2469563lfb.583.1665179391416; Fri, 07 Oct 2022 14:49:51 -0700 (PDT) MIME-Version: 1.0 References: <20221004134728.55499-1-kraxel@redhat.com> In-Reply-To: <20221004134728.55499-1-kraxel@redhat.com> From: "Ard Biesheuvel" Date: Fri, 7 Oct 2022 23:49:40 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v2 0/4] OvmfPkg: make better use of physical address space. To: devel@edk2.groups.io, kraxel@redhat.com Cc: Jordan Justen , Pawel Polawski , Jiewen Yao , Oliver Steffen , Ard Biesheuvel Content-Type: text/plain; charset="UTF-8" Merged #3449 into master. On Tue, 4 Oct 2022 at 15:47, Gerd Hoffmann wrote: > > For historical reasons ovmf is quite conservative on address space > usage, to play safe and avoid using more than 36 physical address bits > (the guaranteed minimum) if possible. With devices (specifically GPUs) > becoming larger and larger pci memory bars this becomes increasingly > problematic. > > This patch series address that by trying to figure what the physical > address space size is (which is a bit tricky, see patch #1 for details). > If that worked scale up the 64-bit mmio window and also pcie bridge > windows dynamically with the available address space. > > v2: > - fix pcie bridge window logic, track prefetchable and non-prefetchable > default state separately (Laszlo). > > Gerd Hoffmann (4): > OvmfPkg/PlatformInitLib: qemu cpuid physbits detection > OvmfPkg/PlatformInitLib: detect physical address space > OvmfPkg/PlatformInitLib: dynamic mmio window size > OvmfPkg/PciHotPlugInitDxe: reserve more mmio space > > OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf | 1 + > OvmfPkg/Library/PlatformInitLib/MemDetect.c | 143 ++++++++++++++++--- > OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.c | 21 ++- > 3 files changed, 145 insertions(+), 20 deletions(-) > > -- > 2.37.3 > > > > > >