From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Fish Subject: Re: [edk2] Passing Xen memory map and resource map to OVMF Date: Thu, 14 Nov 2013 08:42:39 -0800 Message-ID: <746A3CCD-E629-4AD5-9889-3BC89A7814F9__19291.8551540517$1384448097$gmane$org@apple.com> References: <20131112183321.GN13369@zion.uk.xensource.com> <52827C0B.5040901@redhat.com> <1384326219.3560.9.camel@nilsson.home.kraxel.org> <20131113115811.GC4948@zion.uk.xensource.com> <1384350814.3560.24.camel@nilsson.home.kraxel.org> <20131113140654.GF4948@zion.uk.xensource.com> <1384352585.3560.36.camel@nilsson.home.kraxel.org> <20131113165644.GA16969@zion.uk.xensource.com> <1384415898.15534.15.camel@nilsson.home.kraxel.org> <5284AEA4.6090004@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: In-reply-to: <5284AEA4.6090004@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: edk2-devel@lists.sourceforge.net Cc: Igor Mammedov , Gerd Hoffmann , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Nov 14, 2013, at 3:06 AM, Laszlo Ersek wrote: > On 11/14/13 08:58, Gerd Hoffmann wrote: >> Hi, >> = >>>>> OVMF >>>>> should just use whatever it gets. >>>> = >>>> What would OVMF use them for? >>>> = >>> = >>> To reserve range for MMIO holes, so that later PCI resource >>> allocation protocol can only use those ranges. >> = >> I'm still not convinced you need that in the first place. >> = >> When booting seabios @ xen it is not needed. pci ressource allocation >> is handled by hvmloader. apci tables (and the ressources declared >> therein) are handled by hvmloader. seabios doesn't touch the pci bars >> and passes through the apci tables -> guest os is happy. >> = >> So why ovmf should be different? IMHO it should operate like seabios >> and NOT do pci ressource allocation when running on xen. Ressources >> are already handled already by hvmloader. Doing it again is (a) >> pointless and (b) creates problems like the one we are discussion >> right now. > = > The PEI (Pre-EFI Initialization) phase in UEFI has to produce a series > of hand-off blocks (HOBs) that describe a bunch of things for the later > phases of UEFI. One such set of information is the memory map used eg. > by the memory management functions called from drivers and applications. > ACPI tables are not enough. > = > So, these HOBs in PEI must come from somewhere. (Platform initialization > is officially platform-specific, so if on your platform ACPI tables come > to existence first, at some location in memory, you can key off those > when exporting the HOBs.) > = Assuming the info you need is in static ACPI tables. I thought the abstract= ion of PCI in ACPI was via a root bridge method and you need a full blown i= nterpreter to read it. There is an Open Source ACPI interpreter, from Intel= , but it seems like overkill. From a standards point of view we have gotten= requests in the past from OS vendors to expose some information that was i= n the ACPI name space as it was need before the OS ACPI interpreter would b= e available=85. Also assuming everything is behind PCI that has been enumerated seems like = a very PC centric view of the world. A lot of ARM SoC devices don=92t have = PCI, but just memory mapped registers. Hiding everything behind PCI is a PC= trick to make Windows work. So for generic hardware some kind of table tha= t describes the memory map seems useful. = > The memmap-related HOBs we currently export in > "OvmfPkg/PlatformPei/Platform.c" are basically static, they only depend > on the memory size retrieved from the CMOS. I can imagine that more > flexibility is needed. > = > Also, PCI resource allocation (enumeration etc.) is just part of the PCI > bus driver in UEFI. Sometime earlier I wrote > = >> The MMIO range is allocated like this: >> = >> PciEnumerator() [MdeMo= dulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c] >> PciHostBridgeResourceAllocator() [MdeMod= ulePkg/Bus/Pci/PciBusDxe/PciLib.c] >> NotifyPhase (PciResAlloc, EfiPciHostBridgeAllocateResources) [MdeMod= ulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c] >> NotifyPhase() [PcAtCh= ipsetPkg/PciHostBridgeDxe/PciHostBridge.c] >> CoreAllocateMemorySpace() [MdeMod= ulePkg/Core/Dxe/Gcd/Gcd.c] >> CoreAllocateSpace() >> = The PI Spec. GCD (Global Coherency Domain) services manage address space. S= o some chunk of address space needs to be allocated to system memory, to PC= I config space, to PCI MMIO space ect. = >> The memory map base comes from CoreInitializeGcdServices() / >> MemMapInitialization(). > = > The MemMapInitialization() function (in > "OvmfPkg/PlatformPei/Platform.c") mentioned in the quote is what we're > discussing now, that's what produces those early HOBs. > = > (Corrections welcome to whatever I said in this email.) > = >>From a UEFI spec perspective you only need to produce EFI_PCI_ROOT_BRIGE_IO= _PROTOCOL and a EFI_PCI_IO_PROTOCOL per device. This is all that is require= d to make generic UEFI code (all the PCI drivers, shell commands, etc.) wor= k. = The https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Bus/Pci/Pci= BusDxe/ driver assumes you are following the PI Spec model and a full PCI e= numeration is requires and a set of chipset/platform specific protocols are= provided to make the PCI enumerate code generic. = There are other examples in the edk2 where PCI enumeration is not required: 1) DUET, as the PCI enumeration has already been done. You can see in https= ://svn.code.sf.net/p/edk2/code/trunk/edk2/DuetPkg/DuetPkgX64.dsc that the U= EFI required protocols for PCI are implemented in DuetPkg/PciRootBridgeNoEn= umerationDxe/PciRootBridgeNoEnumeration.inf and DuetPkg/PciBusNoEnumeration= Dxe/PciBusNoEnumeration.inf 2) The BeagleBoard does not have PCI, but it produces a fake set of PCI int= erfaces to reuse some of the EFI PCI drivers. See https://svn.code.sf.net/p= /edk2/code/trunk/edk2/Omap35xxPkg/PciEmulation/ Hope this helps, Andrew Fish > Thanks > Laszlo > = > -------------------------------------------------------------------------= ----- > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access > Free app hosting. Or install the open source package on any LAMP server. > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! > http://pubads.g.doubleclick.net/gampad/clk?id=3D63469471&iu=3D/4140/ostg.= clktrk > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel