On Thu, Jul 27, 2023 at 02:04:46PM +0200, Igor Mammedov wrote: > On Thu, 27 Jul 2023 16:29:19 +0530 > Sunil V L <suni...@ventanamicro.com> wrote: > > > On Mon, Jul 24, 2023 at 05:32:54PM +0200, Igor Mammedov wrote: > > > On Wed, 12 Jul 2023 22:09:37 +0530 > > > Sunil V L <suni...@ventanamicro.com> wrote: > > > > > > > PCIe High MMIO base is actually dynamic and fixed at > > > > run time based on the RAM configured. Currently, this is > > > > not part of the memmap and kept in separate static variable > > > > in virt.c. However, ACPI code also needs this information > > > > to populate DSDT. So, once the base is discovered, merge > > > > this into the final memmap which can be used to create > > > > ACPI tables later. > > > > > > can ACPI code fetch virt_high_pcie_memmap at runtime from > > > host bridge (like we do in pc/q35)? > > > > > Hi Igor, > > > > Looking at the current design of virt machines (arm/loongarch/riscv), > > getting this directly from the memmap looks simpler. ARM ACPI also uses > > the memmap to get the pcie_high space. It appears to me we need some > > more infrastructure code if ACPI needs to fetch from host bridge. I am > > not sure why that would be beneficial. > > Sure it's possible to directly hardcode access, but it becomes machine > specific and hard to generalize/reuse (defaults might belong to machine, > but ACPI shall pickup these from actual owner - hostbridge). > > And no extra infrastructure is need, x86 manages to do that by > using properties on host bridge (one can pre-program values on host bridge > during it's creation, firmware can also change them later when initializing > PCI). > Then DSDT generator picks up uptodate values from hostbridge > (which is actual owner of these values) via properties. > (basically copy pc/q35 approach). > Ahh OK. Thanks!. Let me update.
Thanks, Sunil
