From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 0A12B21D28FE9 for ; Tue, 25 Jul 2017 17:11:50 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2017 17:13:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,413,1496127600"; d="scan'208";a="1199330006" Received: from adlam-mobl7.amr.corp.intel.com (HELO localhost) ([10.254.187.110]) by fmsmga002.fm.intel.com with ESMTP; 25 Jul 2017 17:13:38 -0700 MIME-Version: 1.0 To: Laszlo Ersek , edk2-devel-01 Message-ID: <150102801569.20332.10802753116663936503@jljusten-skl> From: Jordan Justen In-Reply-To: <20170711032231.29280-2-lersek@redhat.com> Cc: "Dr. David Alan Gilbert" References: <20170711032231.29280-1-lersek@redhat.com> <20170711032231.29280-2-lersek@redhat.com> User-Agent: alot/0.5.1 Date: Tue, 25 Jul 2017 17:13:35 -0700 Subject: Re: [PATCH 1/1] OvmfPkg/PlatformPei: support >=1TB high RAM, and discontiguous high RAM X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 00:11:50 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2017-07-10 20:22:31, Laszlo Ersek wrote: > +STATIC > +EFI_STATUS > +E820HighRamIterate ( > + IN E820_HIGH_RAM_ENTRY_CALLBACK Callback, > + IN OUT VOID *Context > + ) I think a simpler option would be: STATIC EFI_STATUS ScanOrAddE820HighRam ( IN E820_HIGH_RAM_ENTRY_CALLBACK Callback, OUT UINT64 *MaxAddress OPTIONAL ) If MaxAddress !=3D NULL, then scan for it, otherwise add HOBs. Do you anticipate future needs where the iterate callback could be helpful? You might also consider ScanOrAdd64BitE820Ram to somewhat clarify that the 'HighRam' is addresses that don't fit in 32 bits. > + QemuFwCfgSelectItem (FwCfgItem); > + for (Processed =3D 0; Processed < FwCfgSize; Processed +=3D sizeof E82= 0Entry) { > + QemuFwCfgReadBytes (sizeof E820Entry, &E820Entry); > + DEBUG (( > + DEBUG_VERBOSE, > + "%a: Base=3D0x%Lx Length=3D0x%Lx Type=3D%u\n", > + __FUNCTION__, > + E820Entry.BaseAddr, > + E820Entry.Length, > + E820Entry.Type > + )); > + if (E820Entry.Type =3D=3D EfiAcpiAddressRangeMemory && > + E820Entry.BaseAddr >=3D BASE_4GB) { I guess at least for IA32/X64, today, and for the foreseeable future the firmware device will cause a break at 4GB. It seems like we could just check for the end of the range to be above 4GB to easily remove this assumption, right? -Jordan