WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [RFC, PATCH 17/24] i386 Vmi msr patch

To: Andi Kleen <ak@xxxxxxx>
Subject: [Xen-devel] Re: [RFC, PATCH 17/24] i386 Vmi msr patch
From: Zachary Amsden <zach@xxxxxxxxxx>
Date: Tue, 14 Mar 2006 10:03:58 -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:16:20 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <200603141843.24159.ak@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <200603131812.k2DICGJE005747@xxxxxxxxxxxxxxxxxxx> <200603141723.54365.ak@xxxxxxx> <4416F038.90707@xxxxxxxxxx> <200603141843.24159.ak@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5 (X11/20051201)
Andi Kleen wrote:
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.

Don't change it then?

I misunderstood you. I thought when you said, "I don't think it's a good idea virtualize the TSC without CPU support" that meant on CPUs without a hardware TSC. If you really meant on CPUs without virtualization hardware, well, that is something we do, and it is not only possible, it is necessary for many non-paravirtualized operating systems. As I mention in the interface documentation, TSC and the performance counters in general are very problematic in a virtual machine - they can be visible to userspace, and they are hard to keep accurate. Long term, dropping kernel usage of the TSC is a good thing to do for VMs.

The primary motivation for the change here was to get rid of the call to the VMI ROM for TSC support. I am in the process of removing the ROM call sites so that they can instead be patched into the kernel directly. I am actually unsure if there are any uses of the TSC left on critical paths with the new VMI timer support, but I inlined the code here for consistency.

I agree that long term, it doesn't need to be done, and these instructions can all go back to trap and emulate. Perhaps they are even worth dropping from the list of VMI calls, since they really are problematic and/or not useful in a virtual machine. This again, is a good point for debate. We're open to suggestions, but keep in mind that the fact that other operating systems and hypervisors might find something useful in virtualizing them. Maybe not.

BTW I think it will be pretty tough to find enough competent reviewers
for your patchkit.

And is the spec still in flux or are you trying to implement an interface
for an specification that is already put into stone?

Everything is still very much open to change, and nothing is cast in stone - this is about finding the best interface for Linux, and it is clear that it needs some iteration before that is found. Which is why we are looking for feedback, exactly like this.

Thanks,

Zach

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel