On 08/02/2010 10:58 AM, Gleb Natapov wrote:
On Mon, Aug 02, 2010 at 08:04:20AM +0300, Avi Kivity wrote:
On 08/01/2010 04:27 PM, Gleb Natapov wrote:
When we are going to enable e_i_g_s by default?
Optimistically, 2.6.37, so six months.
May be we have enough
time to fix userspace?
Sure we do, but will users update?
0.12 is mature enough that some users will forget about it and not
update it.
So they will not update kernel too. 0.12/2.6.32 should be mature combo.
And we can add patch to 0.12/0.13 stable to work on newer kernels.
We don't know what they'll do. API stability means we only change
things to fix bugs.
But
realistically the problem will occur only if TPR access is done from big
real mode by Windows XP running on old Intel cpus. What are the chances
that this will be a problem in practice?
Windows XP does use big real mode (I think unintentionally, some segment
registers aren't cleared).
Too ancient userspace already does not run on recent
kvm. Or may be we can make userspace enable e_i_g_s per guest. This way
userspace that knows it is OK can tell kernel so.
Let's make it the other way round, enable the optimization for
userspace that declares that it does not make use of rip during
emulation (kvm-tpr-opt can be changed by queueing a signal and
re-entering the guest to complete the operation).
Later we can make the optimization unconditional.
What do you call "optimization"? e_i_g_s=1? Isn't it the same as I proposed
then?
The optimization is your patch.
Step 1: only enable the optimization if userspace indicates it can
handle it.
<time passes>
Step 2: drop the backwards compatibility code, always enable the
optimization.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
