From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: [PATCH] xen/x86: Force removal of memory range when not covered by MTRRs Date: Fri, 15 Feb 2013 12:31:53 +0100 Message-ID: <511E1CA9.7080000@canonical.com> References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com> <511E0BBE02000078000BE9A8@nat28.tlf.novell.com> <511E0F34.6010107@canonical.com> <511E268002000078000BE9FA@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6764879784649301016==" Return-path: In-Reply-To: <511E268002000078000BE9FA@nat28.tlf.novell.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: Jan Beulich Cc: Konrad Rzeszutek Wilk , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============6764879784649301016== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig9308D58B7775E0CF205389A4" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9308D58B7775E0CF205389A4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 15.02.2013 12:13, Jan Beulich wrote: >>>> On 15.02.13 at 11:34, Stefan Bader wrot= e: >> On 15.02.2013 10:19, Jan Beulich wrote: >>>>>> On 14.02.13 at 18:11, Stefan Bader wr= ote: >>>> On a machine that could not cover all its RAM with MTRR ranges, >>>> a crash on boot as dom0 was caused by dom0 trying to create >>>> kernel mapping tables for the clipped range. >>>> >>>> (XEN) WARNING: MTRRs do not cover all of memory. >>>> (XEN) Truncating RAM from 9109504kB to 9043968kB >>>> ... >>>> (XEN) 0000000228000000 - 000000022c000000 (unusable) >>>> ... >>>> [ 0.000000] init_memory_mapping: 0000000228000000-000000022c00000= 0 >>>> [ 0.000000] 0228000000 - 022c000000 page 4k >>>> [ 0.000000] kernel direct mapping tables up to 22c000000 @ >>>> 1e97d8000-1e97fa000 >>>> (XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 002280= 00 >>>> (XEN) mm.c:1222:d0 Failure in alloc_l1_table: entry 0 >>>> (XEN) mm.c:2177:d0 Error while validating mfn 81de (pfn 1e97d8) for >>>> type 1000000000000000: caf=3D8000000000000003 taf=3D1000000000= 000001 >>>> (XEN) mm.c:2985:d0 Error while pinning mfn 81de >>>> >>>> Setting the range in E820 to E280_UNUSABLE seems ambigous as >>>> this is the same type that gets used for memory to be used only >>>> as guest memory (using dom0_mem=3D). >>> >>> Since when is E820_UNUSABLE memory being used as guest >>> memory? If that's indeed the case, that's the bug to fix. The >>> above data to me shows, however, that the range above >>> 228000000 is considered invalid. So then the question is why the >>> kernel tries to map that memory in the first place (the hypervisor >>> rejecting the attempt, despite Dom0 being privileged, seems >>> correct to me, as the range is also known not to be MMIO). >> >> That seems to be done for a while now... On my testbox, when using=20 >> dom0_mem=3D: >> >> (XEN) 00000000dfe9e000 - 00000000dfea0000 type 9 >> (XEN) 00000000dfea0000 - 00000000dfeb2000 (ACPI data) >> (XEN) 00000000dfeb2000 - 00000000dfee0000 (ACPI NVS) >> (XEN) 00000000dfee0000 - 00000000f0000000 (reserved) >> (XEN) 00000000ffe00000 - 0000000100000000 (reserved) >> (XEN) 0000000100000000 - 0000000820000000 (usable) >=20 > All that counts is what you see above. >=20 >> In dom0: >> [ 0.000000] Xen: [mem 0x00000000dfe9e000-0x00000000dfe9ffff] type 9= >> [ 0.000000] Xen: [mem 0x00000000dfea0000-0x00000000dfeb1fff] ACPI d= ata >> [ 0.000000] Xen: [mem 0x00000000dfeb2000-0x00000000dfedffff] ACPI N= VS >> [ 0.000000] Xen: [mem 0x00000000dfee0000-0x00000000efffffff] reserv= ed >> [ 0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserv= ed >> [ 0.000000] Xen: [mem 0x00000000fec20000-0x00000000fec20fff] reserv= ed >> [ 0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserv= ed >> [ 0.000000] Xen: [mem 0x00000000ffe00000-0x00000000ffffffff] reserv= ed >> [ 0.000000] Xen: [mem 0x0000000100000000-0x00000002e063ffff] usable= >> [ 0.000000] Xen: [mem 0x00000002e0640000-0x000000081fffffff] unusab= le >=20 > What Dom0 does to its representation of the E820 map is of no > concern to the hypervisor. So are we in agreement then that the > hypervisor code is fine without any changes? Yes, if we also agree that using unusable for something that is then used= is wrong. So lets drop the xen patch and I try to figure fixing the kernel. -Stefan --------------enig9308D58B7775E0CF205389A4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCgAGBQJRHhypAAoJEOhnXe7L7s6jBPQP/i1b2mz6f0aflYheSnsKbgNe KS04lFOGIN087FLNhY5qVNqj5fVxusXE2Rszq/IGlWg3Hv0SJj6176B0vK7ljKeT ZR5nXDPBhfwIGJGfjhb0i6/jP37W+1ATGxNHBaCP3PguI33MJQHn5D2GwXZ1Hsbi 4y3WGiMx9nW3LWBRTZfE7MMAZpaVmUUuvRgnDfqN5ol4dLNjHPNt8N+u/CaukuVm iwaMdeSsDpotqk06LzrPykr19DxKhql0DoUz0M1Eo7uNLWRDO9HPHOrU0nxqh/7a CLybSNKRLUqDIBGmaOynxtHjjZd+43hhcbiiFei8SBo3Pc4tR6Qv3g3BU9xYufso nFA41OBx8QfgU2JItKAiFGbP6gMBZUokziPMfYUI4yBN+EVxdsO/9sRQW1Sh6fzU zyQjdwyhvDNawrUUH+yAfwMhzhnlikC5HS/Q/1dA6zoGbOuE8SxzPQYMlBKFpHGb t1uSVn0Fs8O/a/piowuaAaKUofViq0y4q2zFmtKfeEDVxcU/GNE73TcCu4Rxizy4 Y07dK4U9WWh4c8W8g4aabQldOyLcNran2HLUvicgYNDW4y0Xms6/2G5SNCLkqPiw 6Rw37+JRXCMzrpMGkEVwA7/9O2iObGO8Qd9CNK14uILdfpcVZK9R7JSPldJ7MoAR fEoawRIJf6ywESuebAkA =8OM+ -----END PGP SIGNATURE----- --------------enig9308D58B7775E0CF205389A4-- --===============6764879784649301016== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6764879784649301016==--