From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1a2JVH-0006TH-RQ for mharc-grub-devel@gnu.org; Fri, 27 Nov 2015 08:55:59 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2JVF-0006TA-P7 for grub-devel@gnu.org; Fri, 27 Nov 2015 08:55:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a2JVE-00021S-QQ for grub-devel@gnu.org; Fri, 27 Nov 2015 08:55:57 -0500 Received: from mail-wm0-x230.google.com ([2a00:1450:400c:c09::230]:32792) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2JVE-00021O-H5 for grub-devel@gnu.org; Fri, 27 Nov 2015 08:55:56 -0500 Received: by wmec201 with SMTP id c201so71532860wme.0 for ; Fri, 27 Nov 2015 05:55:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=FJWNezzRcbKQPjwVRM22/NR0CHGG8CNFRsKevzY+J/M=; b=aKbyQyfvI67U/l7MuLwUzpYOOpgsZ7yAgGpfy+vLJfm9+anDL/WgNkwUM5sXpICy8G /1JJyBhoUeNeVpG6xMic0Wi4tSltcEpZsihV7P50w598IgSJd1J7mIs5cRWI1xDPueMk 1cGyeLOB/7X7Pup2kQAxRM0ItDBuV3HKvPeQOCtgVDSupqu867StOX3PSPgePnUAg6IP zSyok8FaQgUt2+k+Iwq6X4+0PDWdxUo3nORm6KKERTU32JV620QoUanZaBpF3kKVzpjL 5VG/1+h9QuRWRqG5JBOd2vVRNjOJK5KP4E++/qgr/aYTVZXHzQ/skFnBDYnbt/0m5gm8 HyMw== X-Received: by 10.194.109.169 with SMTP id ht9mr32317346wjb.13.1448632555958; Fri, 27 Nov 2015 05:55:55 -0800 (PST) Received: from ?IPv6:2620:0:105f:fd00:a2a8:cdff:fe64:b3b5? ([2620:0:105f:fd00:a2a8:cdff:fe64:b3b5]) by smtp.gmail.com with ESMTPSA id lx4sm32916481wjb.5.2015.11.27.05.55.54 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Nov 2015 05:55:54 -0800 (PST) Subject: Re: grub causing NVDIMMs to be treated as normal memory To: The development of GNU GRUB References: <94D0CD8314A33A4D9D801C0FE68B40295BE539AF@G9W0745.americas.hpqcorp.net> <5655FFC3.9030603@gmail.com> <94D0CD8314A33A4D9D801C0FE68B40295BE5549A@G9W0745.americas.hpqcorp.net> <56567CC3.3040405@gmail.com> <94D0CD8314A33A4D9D801C0FE68B40295BE55713@G9W0745.americas.hpqcorp.net> <56573973.9060806@gmail.com> <94D0CD8314A33A4D9D801C0FE68B40295BE56257@G9W0745.americas.hpqcorp.net> <5657D4CD.7060205@gmail.com> <94D0CD8314A33A4D9D801C0FE68B40295BE575A4@G9W0745.americas.hpqcorp.net> <5658399A.8020101@gmail.com> From: =?UTF-8?Q?Vladimir_'=cf=86-coder/phcoder'_Serbinenko?= Message-ID: <565860DF.8090709@gmail.com> Date: Fri, 27 Nov 2015 14:55:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UjlbjKxJOglmq8UXwl0oi5clS25Rn7vwr" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::230 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2015 13:55:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UjlbjKxJOglmq8UXwl0oi5clS25Rn7vwr Content-Type: multipart/mixed; boundary="------------030805020909050304010809" This is a multi-part message in MIME format. --------------030805020909050304010809 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable New version attached >> GRUB_MEMORY_COREBOOT_TABLES =3D 16, >> GRUB_MEMORY_CODE =3D 20, >> /* This one is special: it's used internally but is never reporte= d >>>>> Note (b): The internal GRUB_MEMORY_CODE (20) value is >>>>> leaking through to the E820 table. >>>>> >>>>> That appears to be from this patch on 2013-10-14: >>>>> 6de9ee86 Pass-through unknown E820 types >>>> >>>> If we are discussing ACPI 6.0 systems here, it explicitly says that >>>> values above 12 should be treated as reserved. Does it cause >>>> problems? >>> >>> All undefined values are reserved for future standardization; >>> the meaning they might have in the future is unpredictable. >>> >>> Software compatible with ACPI 6.0 is supposed to treat them as >>> reserved, but software compatible with a future version of ACPI >>> might interpret them as having some different meaning that isn't >>> compatible with GRUB_MEMORY_CODE. >>> >>> Some companies used e820 type 12 to mean persistent memory without >>> getting that assigned by the ACPI WG, so that value was >>> contaminated. We should probably mark 20 as contaminated too, >>> given this issue. >>> >> I see now that we have leaked 16 (coreboot tables) as well. Could we >> mark 16 as contaminated as well? >> For memory code: should we just pass reserved in linux e820 or is it >> better to keep doing this bug given possible reliance on it by other >> software? >=20 > I think it is better to leave it as is as long as those values can be r= eserved. >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >=20 --------------030805020909050304010809 Content-Type: application/x-patch; name="pram.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pram.diff" ZGlmZiAtLWdpdCBhL2dydWItY29yZS9tbWFwL2VmaS9tbWFwLmMgYi9ncnViLWNvcmUvbW1h cC9lZmkvbW1hcC5jCmluZGV4IDkwMGE0ZDYuLjJiZWZmZTIgMTAwNjQ0Ci0tLSBhL2dydWIt Y29yZS9tbWFwL2VmaS9tbWFwLmMKKysrIGIvZ3J1Yi1jb3JlL21tYXAvZWZpL21tYXAuYwpA QCAtMTE4LDYgKzExOCwxMSBAQCBncnViX2VmaV9tbWFwX2l0ZXJhdGUgKGdydWJfbWVtb3J5 X2hvb2tfdCBob29rLCB2b2lkICpob29rX2RhdGEsCiAJCUdSVUJfTUVNT1JZX05WUywgaG9v a19kYXRhKTsKIAkgIGJyZWFrOwogCisJY2FzZSBHUlVCX0VGSV9NRU1PUllfUEVSU0lTVEVO VDoKKwkgIGhvb2sgKGRlc2MtPnBoeXNpY2FsX3N0YXJ0LCBkZXNjLT5udW1fcGFnZXMgKiA0 MDk2LAorCQlHUlVCX01FTU9SWV9QRVJTSVNURU5ULCBob29rX2RhdGEpOworCSAgYnJlYWs7 CisKIAlkZWZhdWx0OgogCSAgZ3J1Yl9wcmludGYgKCJVbmtub3duIG1lbW9yeSB0eXBlICVk LCBjb25zaWRlcmluZyByZXNlcnZlZFxuIiwKIAkJICAgICAgIGRlc2MtPnR5cGUpOwpAQCAt MTU4LDYgKzE2Myw4IEBAIG1ha2VfZWZpX21lbXR5cGUgKGludCB0eXBlKQogCiAgICAgY2Fz ZSBHUlVCX01FTU9SWV9OVlM6CiAgICAgICByZXR1cm4gR1JVQl9FRklfQUNQSV9NRU1PUllf TlZTOworICAgIGNhc2UgR1JVQl9NRU1PUllfUEVSU0lTVEVOVDoKKyAgICAgIHJldHVybiBH UlVCX0VGSV9NRU1PUllfUEVSU0lTVEVOVDsKICAgICB9CiAKICAgcmV0dXJuIEdSVUJfRUZJ X1VOVVNBQkxFX01FTU9SWTsKZGlmZiAtLWdpdCBhL2luY2x1ZGUvZ3J1Yi9lZmkvYXBpLmgg Yi9pbmNsdWRlL2dydWIvZWZpL2FwaS5oCmluZGV4IDI0YTA1YzUuLmQxYjk3OTkgMTAwNjQ0 Ci0tLSBhL2luY2x1ZGUvZ3J1Yi9lZmkvYXBpLmgKKysrIGIvaW5jbHVkZS9ncnViL2VmaS9h cGkuaApAQCAtNDc2LDYgKzQ3Niw3IEBAIGVudW0gZ3J1Yl9lZmlfbWVtb3J5X3R5cGUKICAg ICBHUlVCX0VGSV9NRU1PUllfTUFQUEVEX0lPLAogICAgIEdSVUJfRUZJX01FTU9SWV9NQVBQ RURfSU9fUE9SVF9TUEFDRSwKICAgICBHUlVCX0VGSV9QQUxfQ09ERSwKKyAgICBHUlVCX0VG SV9NRU1PUllfUEVSU0lTVEVOVCwKICAgICBHUlVCX0VGSV9NQVhfTUVNT1JZX1RZUEUKICAg fTsKIHR5cGVkZWYgZW51bSBncnViX2VmaV9tZW1vcnlfdHlwZSBncnViX2VmaV9tZW1vcnlf dHlwZV90OwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS9ncnViL21lbW9yeS5oIGIvaW5jbHVkZS9n cnViL21lbW9yeS5oCmluZGV4IDA4M2NmYjYuLjJlNzM0YjcgMTAwNjQ0Ci0tLSBhL2luY2x1 ZGUvZ3J1Yi9tZW1vcnkuaAorKysgYi9pbmNsdWRlL2dydWIvbWVtb3J5LmgKQEAgLTMwLDYg KzMwLDcgQEAgdHlwZWRlZiBlbnVtIGdydWJfbWVtb3J5X3R5cGUKICAgICBHUlVCX01FTU9S WV9BQ1BJID0gMywKICAgICBHUlVCX01FTU9SWV9OVlMgPSA0LAogICAgIEdSVUJfTUVNT1JZ X0JBRFJBTSA9IDUsCisgICAgR1JVQl9NRU1PUllfUEVSU0lTVEVOVCA9IDcsCiAgICAgR1JV Ql9NRU1PUllfQ09SRUJPT1RfVEFCTEVTID0gMTYsCiAgICAgR1JVQl9NRU1PUllfQ09ERSA9 IDIwLAogICAgIC8qIFRoaXMgb25lIGlzIHNwZWNpYWw6IGl0J3MgdXNlZCBpbnRlcm5hbGx5 IGJ1dCBpcyBuZXZlciByZXBvcnRlZAo= --------------030805020909050304010809-- --UjlbjKxJOglmq8UXwl0oi5clS25Rn7vwr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREKAAYFAlZYYN8ACgkQmBXlbbo5nOu81wD8D8W2BMFdd1FfyIBwttDLNJYw ZLHCzxT66aM8e5NiiLkA/3s07Cw7rC3I42kXpNZFUCwZAIvCHxios2SKDJVFGqvx =/Hth -----END PGP SIGNATURE----- --UjlbjKxJOglmq8UXwl0oi5clS25Rn7vwr--