From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1a2Mk9-0001qb-Jt for mharc-grub-devel@gnu.org; Fri, 27 Nov 2015 12:23:33 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42192) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2Mk4-0001jn-Jd for grub-devel@gnu.org; Fri, 27 Nov 2015 12:23:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a2Mk0-0007xd-Iv for grub-devel@gnu.org; Fri, 27 Nov 2015 12:23:28 -0500 Received: from mail-lf0-x232.google.com ([2a00:1450:4010:c07::232]:35974) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2Mk0-0007xP-B6 for grub-devel@gnu.org; Fri, 27 Nov 2015 12:23:24 -0500 Received: by lfs39 with SMTP id 39so133310943lfs.3 for ; Fri, 27 Nov 2015 09:23:23 -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=fwL6PTDj5X9StDaEnIDO82aSZ1IRVDUcugBfZy4qTLs=; b=iaXJnn82Pav13rgbqtcgoUstzb3fsINHcl4GnNnEGtRaybntpZaDLJAxQr89EMiZNI Uzobye71gKon7GPdtxb4g3Azs2uZbGmcYcAK+RNUWxDbaHjAG69nqfCRzdWa4mSBp+BW qEAoxBGms2HQSvUwCEgavyw5LYKeCxCORh9yEHrFXeq0oYTm64lFdPejrwlaZJDgvJRN 3Pguzpzbica9flghLQQRNG6Ur0GKYgxCG0QDVSiE9ixHAqvoUZ9Vxi/vRKn3UOdSyS6t YWGLdu2qRA77P1y42fHAZDhHerzHYM+msJ4HM4ZxH8y9YUbTQznUwCiJA4sRECTt4M5n 2G0Q== X-Received: by 10.112.141.70 with SMTP id rm6mr9505604lbb.94.1448645003530; Fri, 27 Nov 2015 09:23:23 -0800 (PST) Received: from [192.168.1.41] (ppp91-76-25-247.pppoe.mtu-net.ru. [91.76.25.247]) by smtp.gmail.com with ESMTPSA id l67sm5190814lfl.26.2015.11.27.09.23.22 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Nov 2015 09:23:22 -0800 (PST) Subject: Re: grub causing NVDIMMs to be treated as normal memory To: grub-devel@gnu.org 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> <565860DF.8090709@gmail.com> From: Andrei Borzenkov Message-ID: <56589189.7040203@gmail.com> Date: Fri, 27 Nov 2015 20:23:21 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565860DF.8090709@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A4EOkGImjU26soCPvQaMirtSdN6IAIu3u" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c07::232 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 17:23:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A4EOkGImjU26soCPvQaMirtSdN6IAIu3u Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 27.11.2015 16:55, Vladimir '=CF=86-coder/phcoder' Serbinenko =D0=BF=D0=B8= =D1=88=D0=B5=D1=82: > New version attached >=20 For completeness, there is lsmmap, but it is cosmetic. What about multiboot(2)? It lists possible memory types. Do they constitute binding API? #define MULTIBOOT_MEMORY_AVAILABLE 1 #define MULTIBOOT_MEMORY_RESERVED 2 #define MULTIBOOT_MEMORY_ACPI_RECLAIMABLE 3 #define MULTIBOOT_MEMORY_NVS 4 #define MULTIBOOT_MEMORY_BADRAM 5 >>> GRUB_MEMORY_COREBOOT_TABLES =3D 16, >>> GRUB_MEMORY_CODE =3D 20, >>> /* This one is special: it's used internally but is never report= ed >>>>>> 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? >> >> I think it is better to leave it as is as long as those values can be = reserved. >> >> _______________________________________________ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel >> >=20 >=20 >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >=20 --A4EOkGImjU26soCPvQaMirtSdN6IAIu3u 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.0.22 (GNU/Linux) iEYEARECAAYFAlZYkYkACgkQR6LMutpd94yRFwCgnOC1mSQqYCmlRJ0Sx1oEDugt xNMAoIiefWdKPYkkchHFyYiWFhtHgFv4 =x+ig -----END PGP SIGNATURE----- --A4EOkGImjU26soCPvQaMirtSdN6IAIu3u--