lkml.org 
[lkml]   [2006]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC, PATCH 17/24] i386 Vmi msr patch
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-03-14 19:07    [W:0.037 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site