[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Xen-devel] Re: [RFC, PATCH 17/24] i386 Vmi msr patch
- To: Andi Kleen <ak@xxxxxxx>
- From: Zachary Amsden <zach@xxxxxxxxxx>
- Date: Tue, 14 Mar 2006 08:32:56 -0800
- Cc: Andrew Morton <akpm@xxxxxxxx>, Joshua LeVasseur <jtl@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Pratap Subrahmanyam <pratap@xxxxxxxxxx>, Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxx>, Jack Lo <jlo@xxxxxxxxxx>, Dan Hecht <dhecht@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>, Christopher Li <chrisl@xxxxxxxxxx>, virtualization@xxxxxxxxxxxxxx, Linus Torvalds <torvalds@xxxxxxxx>, Anne Holler <anne@xxxxxxxxxx>, Jyothy Reddy <jreddy@xxxxxxxxxx>, Kip Macy <kmacy@xxxxxxxxxxx>, Ky Srinivasan <ksrinivasan@xxxxxxxxxx>, Leendert van Doorn <leendert@xxxxxxxxxxxxxx>, Dan Arai <arai@xxxxxxxxxx>
- Delivery-date: Wed, 15 Mar 2006 10:15:09 +0000
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
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
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.
Xen-devel mailing list