From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [Linux PATCH] Fix to hugepages to work around new PWT handling Date: Thu, 24 Jun 2010 11:05:21 +0100 Message-ID: <4C232DE1.50008@goop.org> References: <20100609140252.18351.48175.sendpatchset@magnum.int.mccr.org> <201006091335.52854.dcm@mccr.org> <4C0FE359.1000305@goop.org> <201006091426.03926.dcm@mccr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <201006091426.03926.dcm@mccr.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dave McCracken Cc: Xen Developers List List-Id: xen-devel@lists.xenproject.org On 06/09/2010 08:26 PM, Dave McCracken wrote: >> But in general kernel code shouldn't be just nakedly setting present on >> the pte without also remaking the whole thing. That doesn't happen with >> normal ptes, and it probably shouldn't happen with huge ptes. Forcing >> present on a pte at this level seems very bogus. Why not change the >> upper code to set present if that's want it wants? >> >> I'll skip this chunk for now. >> > Um, this is the upper level code. The entire purpose of make_huge_pte is to > construct a present huge pte from page and pgprot. The problem is that the > original code makes the pte, then sets the present bit via pte_mkhuge(). This > means the Xen-specific macro that triggers on present is misled and doesn't do > the pfn_to_mfn(). Without this patch hugepages is handing pfns to the > hypervisor to map instead of mfns. > In principle, setting present should cause the pte to be converted from pfn to mfn, but I don't think that ever happens with normal ptes (since non-present ptes contain swap info). But I don't see where a huge pte gets present set; pte_mkhuge itself doesn't do anything except set PSE. J