From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.20, mailfrom: jordan.l.justen@intel.com) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by groups.io with SMTP; Thu, 13 Jun 2019 00:41:01 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jun 2019 00:41:00 -0700 X-ExtLoop1: 1 Received: from leewonjo-mobl.amr.corp.intel.com (HELO localhost) ([10.251.129.208]) by orsmga008.jf.intel.com with ESMTP; 13 Jun 2019 00:41:00 -0700 MIME-Version: 1.0 In-Reply-To: References: <20190527030350.11996-1-hao.a.wu@intel.com> <18b24dae9f4e5c022849502fc4b60ac3ba59d6f1.camel@infradead.org> Cc: Laszlo Ersek , Ard Biesheuvel From: "Jordan Justen" To: "Ni, Ray" , "Wu, Hao A" , "devel@edk2.groups.io" , "dwmw2@infradead.org" Subject: Re: [edk2-devel] [PATCH 11/10] OvmfPkg/Csm/LegacyBiosDxe: Correct Legacy16GetTableAddress call for E820 data Message-ID: <156041165954.1758.7451081062097429166@jljusten-skl> User-Agent: alot/0.8 Date: Thu, 13 Jun 2019 00:40:59 -0700 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2019-06-12 23:28:12, Wu, Hao A wrote: >=20 > > -----Original Message----- > > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of > > David Woodhouse > > Sent: Thursday, June 13, 2019 5:43 AM > >=20 > > The DX register is supposed to contain the required alignment for the > > allocation. It was zero, and SeaBIOS doesn't (well, didn't) cope well > > with that. Set it appropriately, and set BX to indicate the regions > > it's OK to allocate in too. That was already OK but let's make sure > > it's initialised properly and not just working by chance. > >=20 > > Also actually return an error if the allocation fails. Instead of going > > all the way through into the CSM and just letting it have a bogus > > pointer to the E82o data. 'E82o' =3D> 'E820' > >=20 > > diff --git a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c > > b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c > > index 211750c012..e7766eb2b1 100644 > > --- a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c > > +++ b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c > > @@ -928,7 +928,9 @@ GenericLegacyBoot ( > > if (CopySize > Private->Legacy16Table->E820Length) { > > ZeroMem (&Regs, sizeof (EFI_IA32_REGISTER_SET)); > > Regs.X.AX =3D Legacy16GetTableAddress; > > + Regs.X.BX =3D (UINT16) 0x3; // Region >=20 >=20 > According to the spec: >=20 > ''' > BX =3D Allocation region > 00 =3D Allocate from either 0xE0000 or 0xF0000 64 KB blocks. > Bit 0 =3D 1 Allocate from 0xF0000 64 KB block > Bit 1 =3D 1 Allocate from 0xE0000 64 KB block > ''' >=20 > I think the value 0 for BX is fine which indicates the allocation can > happen in either ranges. Not sure if setting BX to 0x11 is a valid > operation. Based on the spec you quote, it does seem reasonable to expect that a CSM should treat 0 the same as 3, but it is possible that some CSM out there made a silly choice and would blow up on 3. Since David mentioned that bx=3D=3D0 works ok with SeaBIOS CSM, then maybe we should just drop this change? Or, we can add a comment that bx=3D=3D0 means either the e000 or f000 block? -Jordan