All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "H. Peter Anvin" <hpa@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>,
	Ian Campbell <ian.campbell@citrix.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH] x86: use pgd accessors when cloning a pgd range.
Date: Wed, 27 Oct 2010 10:51:44 -0700	[thread overview]
Message-ID: <4CC866B0.8000802@goop.org> (raw)
In-Reply-To: <4CC8649F.5060408@linux.intel.com>

 On 10/27/2010 10:42 AM, H. Peter Anvin wrote:
> On 10/27/2010 10:31 AM, Jeremy Fitzhardinge wrote:
>>   On 10/27/2010 10:18 AM, H. Peter Anvin wrote:
>>> On 10/27/2010 9:50 AM, Jeremy Fitzhardinge wrote:
>>>>
>>>> This never used to be a problem.  Perhaps we can change how
>>>> clone_pgd_range is used at boot time to avoid it in the Xen case
>>>> (since
>>>> we don't care about the secondary pagetable)?
>>>>
>>>
>>> Xen shouldn't have any users of this, since it's used for low-level
>>> operations like SMP bootstrap, suspend to RAM, reboot and low-level
>>> BIOS functionality.
>>>
>>
>> Right, but it is being called smack in the middle of setup_arch().  It
>> looks like they could be hidden away in
>> native_pagetable_setup_start/done though.
>>
>
> This is what makes me absolutely hate paravirt with a passion...
> "let's hid things away in <obscure place> and make it absolutely
> impossible to either follow the code flow or figure out what the
> intended semantics are supposed to be."

Its not really an obscure place; it's where x86-32 does the rest of its
boot-time pagetable adjustments (like cleaning out the low identity
maps, etc).  Having those clone_pgd_ranges() floating around in
setup_arch() is out of place.

> (Let not even get me started on how ill-defined the semantics of some
> of the paravirt operations are.)  In this case, at the most you need a
> single flag of state... or you could even just ignore this low-level
> data structure that you will never use in the first place.  Ian's
> message just mentioned "a failure" and never described in any way what
> kind of "failure" it was.

It would be a pagefault from Xen preventing a direct write to the pgd
level of an active pagetable.  At the point in setup_arch() where it
does the first clone_pgd_range() we're already running on swapper_pg_dir
and the copy from initial_page_table is outright wrong.

As Ian suggests, we could switch Xen to use initial_page_table at boot
then move to swapper_pg_dir in the same way native does.

    J

  parent reply	other threads:[~2010-10-27 17:51 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-27  8:50 [PATCH] x86: use pgd accessors when cloning a pgd range Ian Campbell
2010-10-27 10:40 ` Borislav Petkov
2010-10-27 16:50   ` Jeremy Fitzhardinge
2010-10-27 17:18     ` H. Peter Anvin
2010-10-27 17:31       ` Jeremy Fitzhardinge
2010-10-27 17:42         ` H. Peter Anvin
2010-10-27 17:51           ` Ian Campbell
2010-10-27 17:51           ` Jeremy Fitzhardinge [this message]
2010-10-27 18:02             ` Ian Campbell
2010-10-27 18:11             ` H. Peter Anvin
2010-10-27 18:51               ` Jeremy Fitzhardinge
2010-10-27 19:00                 ` H. Peter Anvin
2010-10-27 19:02                 ` H. Peter Anvin
2010-10-27 17:44         ` Borislav Petkov
2010-10-27 17:54           ` Jeremy Fitzhardinge
2010-10-27 17:58           ` Ian Campbell
2010-10-28  9:23             ` Ian Campbell
2010-10-28 11:20               ` Borislav Petkov
2010-10-28 11:53                 ` Ian Campbell
2010-10-28 15:49                 ` H. Peter Anvin
2010-10-28 15:48               ` H. Peter Anvin
2010-11-03 15:35               ` Ian Campbell

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=4CC866B0.8000802@goop.org \
    --to=jeremy@goop.org \
    --cc=bp@alien8.de \
    --cc=hpa@linux.intel.com \
    --cc=ian.campbell@citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    /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.