All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zachary Amsden <zach@vmware.com>
To: Zwane Mwaikambo <zwane@arm.linux.org.uk>
Cc: akpm@osdl.org, chrisl@vmware.com, chrisw@osdl.org, hpa@zytor.com,
	Keir.Fraser@cl.cam.ac.uk, linux-kernel@vger.kernel.org,
	m+Ian.Pratt@cl.cam.ac.uk, mbligh@mbligh.org, pratap@vmware.com,
	virtualization@lists.osdl.org
Subject: Re: [PATCH 8/14] i386 / Add a per cpu gdt accessor
Date: Wed, 10 Aug 2005 22:53:43 -0700	[thread overview]
Message-ID: <42FAE7E7.1000502@vmware.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0508102344060.16483@montezuma.fsmlabs.com>

Zwane Mwaikambo wrote:

>On Wed, 10 Aug 2005 zach@vmware.com wrote:
>
>  
>
>>Add an accessor function for getting the per-CPU gdt.  Callee must already
>>have the CPU.
>>    
>>
>
>This one seems superfluous to me, does accessing it indirectly generate 
>better code too?
>  
>

Thanks for the feedback.  I believe the binary compilation is the same.  
It is superfluous in the sense that there is not yet a real use for it, 
but it is needed for later developement.

Xen requires page isolation of system data structures that could be used 
to override privilege.  Since they do not shadow the GDT, they require 
the GDT to be write protected.  A side effect of that is that the GDT 
must be moved to an isolated page.  Thus, the accessors to allow 
transparently moving the GDT for a paravirtual build.  There is 
deliberately no effect on the standard build.

Zach

P.S. Sorry I got your mail address wrong earlier.  I mistyped it from 
the update to the CREDITS patch.

  parent reply	other threads:[~2005-08-11  5:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-11  4:56 [PATCH 8/14] i386 / Add a per cpu gdt accessor zach
2005-08-11  5:45 ` Zwane Mwaikambo
2005-08-11  5:40   ` Chris Wright
2005-08-11  5:43     ` H. Peter Anvin
2005-08-11  5:54       ` Chris Wright
2005-08-11  5:53   ` Zachary Amsden [this message]
2005-08-11  6:06     ` Zwane Mwaikambo
2005-08-16 23:47 ` Andi Kleen
2005-08-16 23:49   ` H. Peter Anvin
2005-08-17  0:07   ` Chris Wright
2005-08-17  0:16     ` Andi Kleen
2005-08-17  0:24       ` Chris Wright

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=42FAE7E7.1000502@vmware.com \
    --to=zach@vmware.com \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=akpm@osdl.org \
    --cc=chrisl@vmware.com \
    --cc=chrisw@osdl.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m+Ian.Pratt@cl.cam.ac.uk \
    --cc=mbligh@mbligh.org \
    --cc=pratap@vmware.com \
    --cc=virtualization@lists.osdl.org \
    --cc=zwane@arm.linux.org.uk \
    /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.