public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: Pedro Falcato <pedro.falcato@gmail.com>
Cc: devel@edk2.groups.io, Isaac Oram <isaac.w.oram@intel.com>,
	Theo Jehl <theojehl76@gmail.com>
Subject: Re: [PATCH edk2-platforms 1/2] QemuOpenBoardPkg: Redo PCI bus initialization
Date: Fri, 13 Jan 2023 07:33:08 +0100	[thread overview]
Message-ID: <20230113063308.rzaqgegewx3pp77i@sirius.home.kraxel.org> (raw)
In-Reply-To: <20230112231359.452800-2-pedro.falcato@gmail.com>

> diff --git a/Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/Memory.c b/Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/Memory.c
> index 21705256191b..4f312c36016e 100644
> --- a/Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/Memory.c
> +++ b/Platform/Qemu/QemuOpenBoardPkg/PlatformInitPei/Memory.c

There is OvmfPkg/Library/PlatformInitLib which you could use instead of
reinventing the wheel ...

If there are changes needed to make PlatformInitLib work for you feel
free to propose patches (same goes for eventually moving code from
OvmfPkg/PlatformPei to the Library).

> +  // It's worth noting that QEMU also grew an option to change lowmem based on the
> +  // user's preferences. Because of all of this, it's near impossible to hardcode
> +  // a range, so we grab TOLUD (not in a literal way, since QEMU does not implement
> +  // that register ;)) and calculate our PCI MMIO based on that. This also makes it so
> +  // the DSDT built by QEMU will have correct _CRS ranges.
> +  // hw/pci-host/q35.c explicitly says our PCI hole ranges from [TOLUD, IO APIC].
> +  // As far as I can tell, we seem to be allowed to add a 64-bit resource range anywhere.

There is a etc/reserved-memory-end fw_cfg FwCfg file.  If present it
the 64-bit resource range should be placed above the address specified
there (qemu uses that to reserve address space if needed, happens for
example when you enable memory hotplug).

The patch should be splitted up into smaller pieces to make it easier
to review the changes.

take care,
  Gerd


  parent reply	other threads:[~2023-01-13  6:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-12 23:13 [PATCH edk2-platforms 0/2] QemuOpenBoardPkg: PCI rework and small fixes Pedro Falcato
2023-01-12 23:13 ` [PATCH edk2-platforms 1/2] QemuOpenBoardPkg: Redo PCI bus initialization Pedro Falcato
2023-01-13  1:46   ` Isaac Oram
2023-01-13  6:33   ` Gerd Hoffmann [this message]
2023-01-30 11:27     ` Pedro Falcato
2023-03-09  3:48       ` [edk2-devel] " Isaac Oram
2023-05-08 23:48         ` Pedro Falcato
2023-01-12 23:13 ` [PATCH edk2-platforms 2/2] QemuOpenBoardPkg: Trivial code cleanup Pedro Falcato
2023-01-13  1:48   ` Isaac Oram
2023-01-13 12:58   ` Théo Jehl

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=20230113063308.rzaqgegewx3pp77i@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