From: "Gerd Hoffmann" <kraxel@redhat.com>
To: devel@edk2.groups.io, ncoleon@amazon.com
Cc: Alexander Graf <graf@amazon.de>
Subject: Re: [edk2-devel] [PATCH v5 4/5] Ovmf/PlatformPei: Use host-provided GPA end if available
Date: Fri, 29 Apr 2022 12:18:41 +0200 [thread overview]
Message-ID: <20220429101841.f6o7mt34utdp4suj@sirius.home.kraxel.org> (raw)
In-Reply-To: <27e815bf6eb94fd36b45a98e760c318a54422012.1650918674.git.ncoleon@amazon.com>
On Mon, Apr 25, 2022 at 11:43:49PM +0200, Ojeda Leon, Nicolas via groups.io wrote:
> Read the "hardware-info" item from fw-cfg to extract specifications
> of PCI host bridges and analyze the 64-bit apertures of them to
> find out the highest 64-bit MMIO address required which determines
> the address space required by the guest, and, consequently, the
> FirstNonAddress used to calculate size of physical addresses.
Is there some way to (a) figure ovmf runs on aws, and (b) figure what
the physical address space is?
IIRC I've mentioned this before: The reason for this FirstNonAddress
logic is that ovmf tries to be very conservative because when running on
qemu 'pc' and 'q35' machine types ovmf simply can't figure reliable how
much address space it actually has.
With qemu 'microvm' machine type this is not the case so standard cpuid
can be used instead:
https://edk2.groups.io/g/devel/message/89260?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Arecentpostdate%2Fsticky%2C%2CmPhysMemAddressWidth%2C20%2C2%2C0%2C90681717
So if using PlatformAddressWidthFromCpuid() as-is or something simliar
is an option this series could be simplified. I think you don't need
to parse hardware-info in PEI then ...
(keeping the series as-is is fine with me too).
take care,
Gerd
next prev parent reply other threads:[~2022-04-29 10:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-25 21:43 [PATCH v5 0/5] Handling of multiple PCI host bridges Ojeda Leon, Nicolas
2022-04-25 21:43 ` [PATCH v5 1/5] OvmfPkg/Library: Create base HardwareInfoLib for PCI Host Bridges Ojeda Leon, Nicolas
2022-04-25 21:43 ` [PATCH v5 2/5] Ovmf/HardwareInfoLib: Create Pei lib to parse directly from fw-cfg Ojeda Leon, Nicolas
2022-04-25 21:43 ` [PATCH v5 3/5] Ovmf/HardwareInfoLib: Add Dxe lib to dynamically parse heterogenous data Ojeda Leon, Nicolas
2022-04-25 21:43 ` [PATCH v5 4/5] Ovmf/PlatformPei: Use host-provided GPA end if available Ojeda Leon, Nicolas
2022-04-29 10:18 ` Gerd Hoffmann [this message]
2022-05-13 8:45 ` [edk2-devel] " Ojeda Leon, Nicolas
2022-05-27 13:05 ` Ojeda Leon, Nicolas
2022-06-01 8:46 ` Gerd Hoffmann
2022-04-25 21:43 ` [PATCH v5 5/5] OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with spec Ojeda Leon, Nicolas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220429101841.f6o7mt34utdp4suj@sirius.home.kraxel.org \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox