From: "H. Peter Anvin" <hpa@linux.intel.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
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:42:55 -0700 [thread overview]
Message-ID: <4CC8649F.5060408@linux.intel.com> (raw)
In-Reply-To: <4CC861F9.8080200@goop.org>
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." (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.
-hpa
next prev parent reply other threads:[~2010-10-27 17:43 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 [this message]
2010-10-27 17:51 ` Ian Campbell
2010-10-27 17:51 ` Jeremy Fitzhardinge
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=4CC8649F.5060408@linux.intel.com \
--to=hpa@linux.intel.com \
--cc=bp@alien8.de \
--cc=ian.campbell@citrix.com \
--cc=jeremy@goop.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox