All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Dave McCracken <dcm@mccr.org>
Cc: Xen Developers List <xen-devel@lists.xensource.com>
Subject: Re: [Linux PATCH] Fix to hugepages to work around new PWT handling
Date: Thu, 24 Jun 2010 11:05:21 +0100	[thread overview]
Message-ID: <4C232DE1.50008@goop.org> (raw)
In-Reply-To: <201006091426.03926.dcm@mccr.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

  reply	other threads:[~2010-06-24 10:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-09 14:02 [Linux PATCH] Fix to hugepages to work around new PWT handling Dave McCracken
2010-06-09 18:21 ` Jeremy Fitzhardinge
2010-06-09 18:35   ` Dave McCracken
2010-06-09 18:54     ` Jeremy Fitzhardinge
2010-06-09 19:26       ` Dave McCracken
2010-06-24 10:05         ` Jeremy Fitzhardinge [this message]
2010-06-24 22:38           ` Dave McCracken

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C232DE1.50008@goop.org \
    --to=jeremy@goop.org \
    --cc=dcm@mccr.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.