From: Zachary Amsden <zach@vmware.com>
To: Chris Wright <chrisw@osdl.org>
Cc: linux-kernel@vger.kernel.org, pratap@vmware.com, chrisl@vmware.com
Subject: Re: [PATCH 2/8] Move privileged processor operations to the subarch layer
Date: Sun, 07 Aug 2005 03:54:36 -0700 [thread overview]
Message-ID: <42F5E86C.5000105@vmware.com> (raw)
In-Reply-To: <20050807010615.GG7762@shell0.pdx.osdl.net>
Chris Wright wrote:
>* Zachary Amsden (zach@vmware.com) wrote:
>
>
>>i386 Transparent Paravirtualization Subarch Patch #2
>>
>>This change encapsulates CPUID and debug register accessors and moves
>>them into the sub-architecture layer.
>>
>>
>
>This one looks to be a superset of Xen version:
>
>
>@@ -453,6 +441,7 @@ struct thread_struct {
> unsigned long v86flags, v86mask, saved_esp0;
> unsigned int saved_fs, saved_gs;
> /* IO permissions */
>+ unsigned long io_pl;
>
>
We also added an iopl field to the thread struct; this was committed to
-rc4-mm1:
The patch titled
x86: make IOPL explicit
has been added to the -mm tree. Its filename is
x86-make-iopl-explicit.patch
diff -puN include/asm-i386/processor.h~x86-make-iopl-explicit include/asm-i386/processor.h
--- devel/include/asm-i386/processor.h~x86-make-iopl-explicit 2005-08-03 23:11:31.000000000 -0700
+++ devel-akpm/include/asm-i386/processor.h 2005-08-03 23:12:06.000000000 -0700
@@ -420,6 +420,7 @@ struct tss_struct {
* Cache the current maximum and the last task that used the bitmap:
*/
unsigned long io_bitmap_max;
+ unsigned long iopl;
struct thread_struct *io_bitmap_owner;
/*
> unsigned long *io_bitmap_ptr;
> /* max allowed port in the bitmap, in bytes: */
> unsigned long io_bitmap_max;
>@@ -487,6 +476,7 @@ static inline void load_esp0(struct tss_
> tss->ss1 = thread->sysenter_cs;
> wrmsr(MSR_IA32_SYSENTER_CS, thread->sysenter_cs, 0);
> }
>+ mach_load_esp0(tss, thread);
>
>
I moved the entire load_esp0() function to the subarch layer. We used
to have a mach_load_esp0(tss, thread) type function. Either way is
acceptable - I sort of prefer your way, but I was concerned that Xen
would not want to support the stashing of the v8086 sysenter CS value in
ss1 (because Xen might not want to shadow the TSS, but use the real one,
which implies ss1 is the real kernel segment). I am sort of less
concerned with this now, because I think that shadowing the TSS is a
really good idea for many reasons, and I believe Xen does this anyway.
In general, a hypervisor must be aware of two things on kernel stack
updates = kernel ESP is essential, but kernel SS is also needed if the
kernel uses alternate stacks. The hypervisor need not know the TSS
pointer itself, since it is either implicit (through TR), or not
required at all (pure hypercall to update the shadow stack).
What to you think of :
include/asm-i386/mach-default/mach_processor.h:
#define mach_update_esp(ss, esp) /* nop */
include/asm-i386/processor.h, in load_esp0():
mach_update_esp0(KERNEL_SS, thread->esp0);
Zach
prev parent reply other threads:[~2005-08-07 10:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-06 7:13 [PATCH 2/8] Move privileged processor operations to the subarch layer Zachary Amsden
2005-08-07 1:06 ` Chris Wright
2005-08-07 10:54 ` Zachary Amsden [this message]
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=42F5E86C.5000105@vmware.com \
--to=zach@vmware.com \
--cc=chrisl@vmware.com \
--cc=chrisw@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pratap@vmware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).