Keir, I''m afraid this change is going to hurt on AMD systems where memory extends beyond the 4Gb boundary: Both such systems that I have direct access to have their Intel MTRRs only defined up to the 4Gb boundary, yet through the use of AMD specific MSRs (SYS_CFG.Tom2ForceMemTypeWB and TOM2) the default memory type for everything beyond the 4Gb boundary is WB. On these systems there shouldn''t be any clipping. I certainly can put together a patch for this, but it''ll take me a couple of days until I''d get to it. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/04/2009 09:53, "Jan Beulich" <jbeulich@novell.com> wrote:> I''m afraid this change is going to hurt on AMD systems where memory extends > beyond the 4Gb boundary: Both such systems that I have direct access to > have their Intel MTRRs only defined up to the 4Gb boundary, yet through > the use of AMD specific MSRs (SYS_CFG.Tom2ForceMemTypeWB and TOM2) > the default memory type for everything beyond the 4Gb boundary is WB. > On these systems there shouldn''t be any clipping. I certainly can put together > a patch for this, but it''ll take me a couple of days until I''d get to it.What do you suggest? Make the clip Intel-specific? We''ve only seen problems with (a very few) Intel boxes, so handling AMD at all may be quite unnecessary. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Keir Fraser <keir.fraser@eu.citrix.com> 29.04.09 11:43 >>> >On 29/04/2009 09:53, "Jan Beulich" <jbeulich@novell.com> wrote: > >> I''m afraid this change is going to hurt on AMD systems where memory extends >> beyond the 4Gb boundary: Both such systems that I have direct access to >> have their Intel MTRRs only defined up to the 4Gb boundary, yet through >> the use of AMD specific MSRs (SYS_CFG.Tom2ForceMemTypeWB and TOM2) >> the default memory type for everything beyond the 4Gb boundary is WB. >> On these systems there shouldn''t be any clipping. I certainly can put together >> a patch for this, but it''ll take me a couple of days until I''d get to it. > >What do you suggest? Make the clip Intel-specific? We''ve only seen problems >with (a very few) Intel boxes, so handling AMD at all may be quite >unnecessary.No - if BIOSes are broken, they can as well be an AMD systems. I''d rather take TOM2 and the mentioned SYS_CFG bit into account in that code (not the least because modern Linux also does so in its MTRR handling code). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 29/04/2009 11:27, "Jan Beulich" <jbeulich@novell.com> wrote:>> What do you suggest? Make the clip Intel-specific? We''ve only seen problems >> with (a very few) Intel boxes, so handling AMD at all may be quite >> unnecessary. > > No - if BIOSes are broken, they can as well be an AMD systems. I''d rather > take TOM2 and the mentioned SYS_CFG bit into account in that code (not > the least because modern Linux also does so in its MTRR handling code).I will consider fixes for theoretical BIOS problems in 3.5. I''m only putting the test at all in 3.3/3.4 because we have actually seen problems on Intel systems, and I will restrict the test to that scope. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Am Mittwoch, den 29.04.2009, 09:53 +0100 schrieb Jan Beulich:> Keir, > > I''m afraid this change is going to hurt on AMD systems where memory extends > beyond the 4Gb boundary: Both such systems that I have direct access to > have their Intel MTRRs only defined up to the 4Gb boundary, yet through > the use of AMD specific MSRs (SYS_CFG.Tom2ForceMemTypeWB and TOM2) > the default memory type for everything beyond the 4Gb boundary is WB. > On these systems there shouldn''t be any clipping. I certainly can put together > a patch for this, but it''ll take me a couple of days until I''d get to it.We can confirm this to be a very real issue. At least on 4 of our test boxes the memory gets truncated after these changes. One example: Mainboard: ASUSTeK Computer INC. M2N-MX SE Plus CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ Family: 15, Model: 107, Stepping: 1 BIOS Information: Vendor: American Megatrends Inc. Version: 0302 Release Date: 12/04/2007 Memory: 4 GB With changeset 19575:dc5bd14a4675: # xm info ... total_memory : 3967 ... # xm dmesg ... (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009fc00 (usable) (XEN) 000000000009fc00 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000b7fb0000 (usable) (XEN) 00000000b7fb0000 - 00000000b7fbe000 (ACPI data) (XEN) 00000000b7fbe000 - 00000000b7fe0000 (ACPI NVS) (XEN) 00000000b7fe0000 - 00000000b7fee000 (reserved) (XEN) 00000000b7ff0000 - 00000000b8000000 (reserved) (XEN) 00000000fec00000 - 00000000fec01000 (reserved) (XEN) 00000000fee00000 - 00000000fef00000 (reserved) (XEN) 00000000fff00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000140000000 (usable) (XEN) System RAM: 3967MB (4062524kB) ... Same box with changeset 19582:648d7de355dd: # xm info ... total_memory : 2943 ... # xm dmesg ... (XEN) WARNING: MTRRs do not cover all of memory. (XEN) Truncating memory map to 3145728kB (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009fc00 (usable) (XEN) 000000000009fc00 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000b7fb0000 (usable) (XEN) 00000000b7fb0000 - 00000000b7fbe000 (ACPI data) (XEN) 00000000b7fbe000 - 00000000b7fe0000 (ACPI NVS) (XEN) 00000000b7fe0000 - 00000000b7fee000 (reserved) (XEN) 00000000b7ff0000 - 00000000b8000000 (reserved) (XEN) System RAM: 2943MB (3013948kB) ... -- Frank Arnold <frank.arnold@amd.com> System Design Technician, Software Test AMD Operating System Research Center Dresden, Germany Tel: +49 351 448 356702 Legal Information: Advanced Micro Devices GmbH Karl-Hammerschmidt-Str. 34 85609 Dornach b. München Geschäftsführer: Jochen Polster; Thomas M. McCoy; Giuliano Meroni Sitz: Dornach, Gemeinde Aschheim, Landkreis München Registergericht München, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir, these log fragments point out another issue: Only RAM regions should be removed, but all other regions should remain. This is not the least because Linux checks the E820 table to have e.g. the MCFG area covered as reserved. Jan>>> Frank Arnold <frank.arnold@amd.com> 29.04.09 19:23 >>>Am Mittwoch, den 29.04.2009, 09:53 +0100 schrieb Jan Beulich:> Keir, > > I''m afraid this change is going to hurt on AMD systems where memory extends > beyond the 4Gb boundary: Both such systems that I have direct access to > have their Intel MTRRs only defined up to the 4Gb boundary, yet through > the use of AMD specific MSRs (SYS_CFG.Tom2ForceMemTypeWB and TOM2) > the default memory type for everything beyond the 4Gb boundary is WB. > On these systems there shouldn''t be any clipping. I certainly can put together > a patch for this, but it''ll take me a couple of days until I''d get to it.We can confirm this to be a very real issue. At least on 4 of our test boxes the memory gets truncated after these changes. One example: Mainboard: ASUSTeK Computer INC. M2N-MX SE Plus CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ Family: 15, Model: 107, Stepping: 1 BIOS Information: Vendor: American Megatrends Inc. Version: 0302 Release Date: 12/04/2007 Memory: 4 GB With changeset 19575:dc5bd14a4675: # xm info ... total_memory : 3967 ... # xm dmesg ... (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009fc00 (usable) (XEN) 000000000009fc00 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000b7fb0000 (usable) (XEN) 00000000b7fb0000 - 00000000b7fbe000 (ACPI data) (XEN) 00000000b7fbe000 - 00000000b7fe0000 (ACPI NVS) (XEN) 00000000b7fe0000 - 00000000b7fee000 (reserved) (XEN) 00000000b7ff0000 - 00000000b8000000 (reserved) (XEN) 00000000fec00000 - 00000000fec01000 (reserved) (XEN) 00000000fee00000 - 00000000fef00000 (reserved) (XEN) 00000000fff00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000140000000 (usable) (XEN) System RAM: 3967MB (4062524kB) ... Same box with changeset 19582:648d7de355dd: # xm info ... total_memory : 2943 ... # xm dmesg ... (XEN) WARNING: MTRRs do not cover all of memory. (XEN) Truncating memory map to 3145728kB (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009fc00 (usable) (XEN) 000000000009fc00 - 00000000000a0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000b7fb0000 (usable) (XEN) 00000000b7fb0000 - 00000000b7fbe000 (ACPI data) (XEN) 00000000b7fbe000 - 00000000b7fe0000 (ACPI NVS) (XEN) 00000000b7fe0000 - 00000000b7fee000 (reserved) (XEN) 00000000b7ff0000 - 00000000b8000000 (reserved) (XEN) System RAM: 2943MB (3013948kB) ... -- Frank Arnold <frank.arnold@amd.com> System Design Technician, Software Test AMD Operating System Research Center Dresden, Germany Tel: +49 351 448 356702 Legal Information: Advanced Micro Devices GmbH Karl-Hammerschmidt-Str. 34 85609 Dornach b. München Geschäftsführer: Jochen Polster; Thomas M. McCoy; Giuliano Meroni Sitz: Dornach, Gemeinde Aschheim, Landkreis München Registergericht München, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 30/04/2009 07:58, "Jan Beulich" <jbeulich@novell.com> wrote:> these log fragments point out another issue: Only RAM regions should be > removed, but all other regions should remain. This is not the least because > Linux checks the E820 table to have e.g. the MCFG area covered as > reserved.I fixed that in c/s 19583. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel