From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by mx.groups.io with SMTP id smtpd.web10.38605.1675078090746702249 for ; Mon, 30 Jan 2023 03:28:10 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20210112 header.b=jhWIuVe3; spf=pass (domain: gmail.com, ip: 209.85.210.179, mailfrom: pedro.falcato@gmail.com) Received: by mail-pf1-f179.google.com with SMTP id 203so6150738pfx.6 for ; Mon, 30 Jan 2023 03:28:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PaFLbMfSMjUb8grUYZc0wTzbpJab41o6JyerearNJ5I=; b=jhWIuVe3jj23NwGbq2prr4FzEC2DoBNqcX9qeuseZ56DmnpFUH0BJx6T3RmKJcxYDJ tST0Yw+29O272xNX01hBJ/7hS1vNj5LHGODuUXh8Ua3jV7JdFJqAr5e1Fzjl2q/r0xH9 6g/0I5sC4LFFMpNlwYKbWC1Ve1hb1+u+46mRWkAx96aSioWkyRblbHmznEQ2E4GOgoyK txWfwhplJrTXkuh5jmUHzypKXTcoxNbn7GicgUXkil/OW9EyiLhb8KBWUnkM7IV6VsIY N8ol/4TvD9MGEPYDD+csE6F6MXC+H8epGsbSTJVkqjdBp8dSpDmi2cMwn7WuuiO8zAyw zVpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PaFLbMfSMjUb8grUYZc0wTzbpJab41o6JyerearNJ5I=; b=dVNBgorTaWtHZ+NM2s6uCEuR+n/eeW8wYrESXxE+EnZDYo4b2NfUO+MzqTDndbqBPA DwCyKEHE7ffo1VdWlbj2DjsqXFCZZZOIpKDwuWTYEBnYb8g5ikSPPi+/J3+zs891cXYB ukgwNbD49wBiKoMaeQWpSo0AKXcV02Ga1wRtSESpGHnMZpJtVhPZvOp2q+Ke5P80hSmt tSVwdhbjHaLyvTgBYGB0/epXVJYGow2EcKm6SbSJm6rklrAPUNZb833YVMi3BnGGLjZE 2E2HXMJyrko/Wt9Tl/LwYte44aHYos7mvu2wZ1pTKJPcgr7G08We5YXF57zzJxeSRYU/ QNGA== X-Gm-Message-State: AFqh2koNqEuMqAxzsotxFN/AxEXtKGyLc3xE958V2BZLfr2d4zgP1qXH 7ActUiTrISBpcsMJdwh+dOOvXLbEFafnkJzzKqs= X-Google-Smtp-Source: AMrXdXuxetpAK8pR4L+D7puGVnJBS0tzBYLyVy0XYQ9dpJHBt2bcki4krSR/1JDrVGvw849I3gMXH0UUWvu1f/wwB+E= X-Received: by 2002:a62:1c86:0:b0:58d:a84a:190b with SMTP id c128-20020a621c86000000b0058da84a190bmr5967536pfc.48.1675078090206; Mon, 30 Jan 2023 03:28:10 -0800 (PST) MIME-Version: 1.0 References: <20230112231359.452800-1-pedro.falcato@gmail.com> <20230112231359.452800-2-pedro.falcato@gmail.com> <20230113063308.rzaqgegewx3pp77i@sirius.home.kraxel.org> In-Reply-To: <20230113063308.rzaqgegewx3pp77i@sirius.home.kraxel.org> From: "Pedro Falcato" Date: Mon, 30 Jan 2023 11:27:59 +0000 Message-ID: Subject: Re: [PATCH edk2-platforms 1/2] QemuOpenBoardPkg: Redo PCI bus initialization To: Gerd Hoffmann Cc: devel@edk2.groups.io, Isaac Oram , Theo Jehl Content-Type: text/plain; charset="UTF-8" On Fri, Jan 13, 2023 at 6:34 AM Gerd Hoffmann wrote: > > > 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). Gerd, Thank you for the comments. That is an interesting idea, however I believe OvmfPkg/Library/PlatformInitLib is ATM a bit too tightly coupled with the rest of OVMF itself. For instance, this work was partially inspired by your recent-ish work in similar OvmfPkg code and also drove me to remove the dependency on PciHostBridgeLib, et al (replacing it with the "standard" MinPlatformPkg PCI libs). My solution is based on dynamic PCD war-crimes but it Just Works(tm). Changing it in OvmfPkg would be too invasive, I feel; it's not like my solution is good or anything. And because of the way the repos are split, there is no way to currently dedup OVMF's PciHostBridgeLib by also making OVMF depend on MinPlatformPkg's, because why would there be, right? Anyway, doing deep changes to OVMF for QemuOpenBoardPkg is uncomfortable for me because its place in Tiano is not defined. OVMF and Intel folks have said very few things about QOBP. At the moment, it's the typical "GSoC project stagnating in edk2-platforms/-staging" that Tianocore seems to love so much. I don't see much point in it being this way. QemuOBP has been a nice fun exercise in reducing code duplication, which shows a lot of promise, but it also doesn't support some of the things OvmfPkg does, like PEI-less booting (and TDX/SEV but those could certainly be worked in). If this kicks off discussion on the future of QemuOpenBoardPkg, I'll be happy. Until that happens, I am reluctant to change OVMF internals for an obscure QEMU PlatformPkg hidden in the best worst repo, edk2-platforms :) > > + // 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). ACK, will change on v2 (together with Isaac's comments). > The patch should be splitted up into smaller pieces to make it easier > to review the changes. Agreed, will try to devise a strategy to break it up in smaller, logical chunks. Again, thank you so much for your time looking at something you're not even a maintainer for :)) -- Pedro