From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: mapping of memory below 16Mb Date: Thu, 24 Jan 2008 16:35:48 +0000 Message-ID: <4798CC74.76E4.0078.0@novell.com> References: <4798C9B8.76E4.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 24.01.08 17:27 >>> >On 24/1/08 16:24, "Jan Beulich" wrote: > >>>> The WP attribute raises another question: Are there any plans to make >>>> Xen use PAT rather than (relying on) MTRRs? Linux folks seem to be >>>> finally getting closer to this, too, so even virtual PAT support may = be >>>> needed in not too distant future... >>>=20 >>> We already support PAT for both PV guests and HVM guests. >>=20 >> Oh, and my understanding of PAT support goes beyond just setting the >> PAT MSR and adjusting page table flags. Specifically, if we have PAT we >> should never need to modify MTRRs, which would eliminate conflicts on >> updates of those that I'm seeing on various boxes, always just >> depending on how BIOS sets them up, and always related to overlaps >> of the video memory with existing MTRR ranges. > >That's a dom0 issue. Xen itself does not proactively mess with the MTRRs. Yes and no: Yes in the sense that Dom0 could be given an alternative hypercall to specify memory types. No in the sense that we already have such a hypercall (setting the MTRRs) that would simply need to do translation to PAT semantics rather than writing to the MTRR MSRs. Jan