From: Zachary Amsden <zach@vmware.com>
To: Andi Kleen <ak@suse.de>
Cc: virtualization@lists.osdl.org, Linus Torvalds <torvalds@osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Xen-devel <xen-devel@lists.xensource.com>,
Andrew Morton <akpm@osdl.org>, Dan Hecht <dhecht@vmware.com>,
Dan Arai <arai@vmware.com>, Anne Holler <anne@vmware.com>,
Pratap Subrahmanyam <pratap@vmware.com>,
Christopher Li <chrisl@vmware.com>,
Joshua LeVasseur <jtl@ira.uka.de>, Chris Wright <chrisw@osdl.org>,
Rik Van Riel <riel@redhat.com>, Jyothy Reddy <jreddy@vmware.com>,
Jack Lo <jlo@vmware.com>, Kip Macy <kmacy@fsmware.com>,
Jan Beulich <jbeulich@novell.com>,
Ky Srinivasan <ksrinivasan@novell.com>,
Wim Coekaerts <wim.coekaerts@oracle.com>,
Leendert van Doorn <leendert@watson.ibm.com>
Subject: Re: [RFC, PATCH 17/24] i386 Vmi msr patch
Date: Tue, 14 Mar 2006 08:32:56 -0800 [thread overview]
Message-ID: <4416F038.90707@vmware.com> (raw)
In-Reply-To: <200603141723.54365.ak@suse.de>
Andi Kleen wrote:
> On Monday 13 March 2006 19:12, Zachary Amsden wrote:
>
>> Fairly straightforward code motion of MSR / TSC / PMC accessors
>> to the sub-arch level. Note that rdmsr/wrmsr_safe functions are
>> not moved; Linux relies on the fault behavior here in the event
>> that certain MSRs are not supported on hardware, and combining
>> this with a VMI wrapper is overly complicated. The instructions
>> are virtualizable with trap and emulate, not on critical code
>> paths, and only used as part of the MSR /proc device, which is
>> highly sketchy to use inside a virtual machine, but must be
>> allowed as part of the compile, since it is useful on native.
>>
>
> I'm not aware of any MSR access being on a critical code
> path on a 32bit kernel.
>
There aren't really any. There are some unexpected ones - such as
setting SYSENTER_CS during a context switch, but only if leaving v8086
mode, which isn't a common case. But most importantly, the MSR
functions were challenging to get correct, because they combine two
novel elements - 64 bit values, as well as non-C calling conventions.
They were actually some of the first functions I inlined, because I knew
there would be problems, and the solutions would yield more powerful
inlining macros.
> And I don't think it's a good idea to virtualize the TSC
> without CPU support.
>
We currently don't support configurations without a TSC. But we're not
trying to virtualize the TSC without CPU support. It is possible. But
I have no idea _why_ you would want to do such a thing.
Zach
next prev parent reply other threads:[~2006-03-14 16:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-13 18:12 [RFC, PATCH 17/24] i386 Vmi msr patch Zachary Amsden
2006-03-13 18:12 ` Zachary Amsden
2006-03-14 16:23 ` Andi Kleen
2006-03-14 16:32 ` Zachary Amsden [this message]
2006-03-14 17:43 ` Andi Kleen
2006-03-14 18:03 ` Zachary Amsden
2006-03-22 20:21 ` Andi Kleen
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=4416F038.90707@vmware.com \
--to=zach@vmware.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=anne@vmware.com \
--cc=arai@vmware.com \
--cc=chrisl@vmware.com \
--cc=chrisw@osdl.org \
--cc=dhecht@vmware.com \
--cc=jbeulich@novell.com \
--cc=jlo@vmware.com \
--cc=jreddy@vmware.com \
--cc=jtl@ira.uka.de \
--cc=kmacy@fsmware.com \
--cc=ksrinivasan@novell.com \
--cc=leendert@watson.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pratap@vmware.com \
--cc=riel@redhat.com \
--cc=torvalds@osdl.org \
--cc=virtualization@lists.osdl.org \
--cc=wim.coekaerts@oracle.com \
--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.