* c/s 19576 vs. AMD systems
@ 2009-04-29 8:53 Jan Beulich
2009-04-29 9:43 ` Keir Fraser
2009-04-29 17:23 ` Frank Arnold
0 siblings, 2 replies; 7+ messages in thread
From: Jan Beulich @ 2009-04-29 8:53 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: c/s 19576 vs. AMD systems
2009-04-29 8:53 c/s 19576 vs. AMD systems Jan Beulich
@ 2009-04-29 9:43 ` Keir Fraser
2009-04-29 10:27 ` Jan Beulich
2009-04-29 17:23 ` Frank Arnold
1 sibling, 1 reply; 7+ messages in thread
From: Keir Fraser @ 2009-04-29 9:43 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel@lists.xensource.com
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: c/s 19576 vs. AMD systems
2009-04-29 9:43 ` Keir Fraser
@ 2009-04-29 10:27 ` Jan Beulich
2009-04-29 10:49 ` Keir Fraser
0 siblings, 1 reply; 7+ messages in thread
From: Jan Beulich @ 2009-04-29 10:27 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel@lists.xensource.com
>>> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: c/s 19576 vs. AMD systems
2009-04-29 10:27 ` Jan Beulich
@ 2009-04-29 10:49 ` Keir Fraser
0 siblings, 0 replies; 7+ messages in thread
From: Keir Fraser @ 2009-04-29 10:49 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel@lists.xensource.com
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: c/s 19576 vs. AMD systems
2009-04-29 8:53 c/s 19576 vs. AMD systems Jan Beulich
2009-04-29 9:43 ` Keir Fraser
@ 2009-04-29 17:23 ` Frank Arnold
2009-04-30 6:58 ` Jan Beulich
1 sibling, 1 reply; 7+ messages in thread
From: Frank Arnold @ 2009-04-29 17:23 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Keir Fraser
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: c/s 19576 vs. AMD systems
2009-04-29 17:23 ` Frank Arnold
@ 2009-04-30 6:58 ` Jan Beulich
2009-04-30 6:59 ` Keir Fraser
0 siblings, 1 reply; 7+ messages in thread
From: Jan Beulich @ 2009-04-30 6:58 UTC (permalink / raw)
To: Keir Fraser; +Cc: Frank Arnold, 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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: c/s 19576 vs. AMD systems
2009-04-30 6:58 ` Jan Beulich
@ 2009-04-30 6:59 ` Keir Fraser
0 siblings, 0 replies; 7+ messages in thread
From: Keir Fraser @ 2009-04-30 6:59 UTC (permalink / raw)
To: Jan Beulich; +Cc: Frank Arnold, xen-devel@lists.xensource.com
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-04-30 6:59 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-04-29 8:53 c/s 19576 vs. AMD systems Jan Beulich
2009-04-29 9:43 ` Keir Fraser
2009-04-29 10:27 ` Jan Beulich
2009-04-29 10:49 ` Keir Fraser
2009-04-29 17:23 ` Frank Arnold
2009-04-30 6:58 ` Jan Beulich
2009-04-30 6:59 ` Keir Fraser
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.