From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: c/s 19576 vs. AMD systems Date: Wed, 29 Apr 2009 11:27:14 +0100 Message-ID: <49F847A2.76EA.0078.0@novell.com> References: <49F8318D.76EA.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 29.04.09 11:43 >>> >On 29/04/2009 09:53, "Jan Beulich" 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