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 11:34:28 +0100 Message-ID: <511E0F34.6010107@canonical.com> References: <1360861916-21243-1-git-send-email-stefan.bader@canonical.com> <511E0BBE02000078000BE9A8@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3729548918811074619==" Return-path: In-Reply-To: <511E0BBE02000078000BE9A8@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: xen-devel@lists.xen.org, Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============3729548918811074619== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig11445852A98028C9EB012F6F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig11445852A98028C9EB012F6F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 15.02.2013 10:19, Jan Beulich wrote: >>>> On 14.02.13 at 18:11, Stefan Bader wrot= e: >> 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-000000022c000000 >> [ 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 00228000= >> (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=3D100000000000= 0001 >> (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). >=20 > 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 dom0_m= em=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) In dom0: [ 0.000000] Xen: [mem 0x00000000dfe9e000-0x00000000dfe9ffff] type 9 [ 0.000000] Xen: [mem 0x00000000dfea0000-0x00000000dfeb1fff] ACPI data= [ 0.000000] Xen: [mem 0x00000000dfeb2000-0x00000000dfedffff] ACPI NVS [ 0.000000] Xen: [mem 0x00000000dfee0000-0x00000000efffffff] reserved [ 0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved [ 0.000000] Xen: [mem 0x00000000fec20000-0x00000000fec20fff] reserved [ 0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved [ 0.000000] Xen: [mem 0x00000000ffe00000-0x00000000ffffffff] reserved [ 0.000000] Xen: [mem 0x0000000100000000-0x00000002e063ffff] usable [ 0.000000] Xen: [mem 0x00000002e0640000-0x000000081fffffff] unusable [ 0.000000] init_memory_mapping: [mem 0x100000000-0x2e063ffff] [ 0.000000] [mem 0x100000000-0x2e063ffff] page 4k [ 0.000000] kernel direct mapping tables up to 0x2e063ffff @ [mem 0x3f163000-0x4006ffff] [ 10.288549] e820: reserve RAM buffer [mem 0xdfe90000-0xdfffffff] [ 10.288555] e820: reserve RAM buffer [mem 0x2e0640000-0x2e3ffffff] There the majority of memory appears as E820_UNUSABLE for dom0 and is use= d for guests. Ok, in that case not trying to do any kernel mappings... Hm, not sure whether I should be worried about that first reserve RAM buf= fer covering the type 9 (whatever that is... I think it appeared when I upgra= ded the BIOS to get IOMMU back after xsa-36) range... It seems to be arch/x86/xen/setup.c:xen_memory_setup() that changes thing= s to unusable... -Stefan >=20 >> To avoid this, the clipped memory should be dropped completely >> from E820 (as it is done if setting the memory type fails). >> This is currently restricted to only the case of memory not >> coverable by MTRRs (which could be tested). Maybe it should >> be done in other cases, too. >=20 > No, that's wrong. When dropping the range completely, the > Dom0 kernel then could allocate MMIO resources in that address > range, and the devices using those MMIO resources then would > not work. >=20 > Bottom line - I think this needs to be fixed in the kernel. >=20 > Jan --------------enig11445852A98028C9EB012F6F 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/ iQIcBAEBCgAGBQJRHg8/AAoJEOhnXe7L7s6jHd8P/RCwATyHCK31aNgvDXhtgIWp M/D1UCtPHbPJD2/xVzLmz2JcAqIpW2FVtQRyNTqeNBTfz0sg8z7oWSwlpUA1Q0QJ ALoUSJ2BrZBb5qwDFYRFxODbuHUtd+G+uSCR6Cs0FE1xR2nbhQEkp/mg66Na8sO4 REgb7asJ9pj1qEFaivS9pCZ2LQt7KWYfNwMsSenxEKritbw1EDnctYcdLRBvZkZf jRuPKM5/DfmW7cYjEX9xJCDmdfzRoG1OZukFb14UGBfWZkq7/NGPfOOzrEWrNdvH jc1lTVAHtY/eLvbeeCLYtlRtgqH+NBULr4ufbJjyk6Q/6LMv4qDlby5nRqWDeaZM 5Z92zCw63Ef2aaQ2TsXtVUSWdLBR3hucfqtN1BDDZzfKzbbWfPMEFGZ4LDi0J96i x+Wizmrz4e9Pn6s3yBceEv1/BfmEzWac/bT8S7Vi2fAwYxS+rILisqfhqdkouLCa QAimOK4DG/zD+bC9yQGW7/nsuBRTeU4W/NtFb+KaGQwU32DXynFGuEELJVekfQDb LLoyqCiLoTKAEYVXKSfRw06l2mfieU4IGtmE6ySmgMkP8wc1a0+Qb75VaFbugJUw AMEksAN8ceTWKtvL2qkCGwuF/jc3NQrLYKY5UCGrgKUP99dIsYNFAyIVOT70C1jh WiFGMrCXkgbq+NNpecge =2gjf -----END PGP SIGNATURE----- --------------enig11445852A98028C9EB012F6F-- --===============3729548918811074619== 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 --===============3729548918811074619==--