From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 1/2] KVM: x86 emulator: don't update vcpu state if instruction is restarted. Date: Mon, 02 Aug 2010 11:03:26 +0300 Message-ID: <4C567BCE.50106@redhat.com> References: <20100801090145.GD24773@redhat.com> <4C553B00.8030100@redhat.com> <20100801092438.GE24773@redhat.com> <4C5545AB.3080806@redhat.com> <20100801105337.GF24773@redhat.com> <4C5565C6.1090004@redhat.com> <20100801122316.GG24773@redhat.com> <4C556A1D.2050105@redhat.com> <20100801132714.GH24773@redhat.com> <4C5651D4.7060905@redhat.com> <20100802075838.GL24773@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mtosatti@redhat.com, kvm@vger.kernel.org To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:1026 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752100Ab0HBID1 (ORCPT ); Mon, 2 Aug 2010 04:03:27 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o7283RV5012368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 2 Aug 2010 04:03:27 -0400 Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com [10.35.255.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o7283QCT024642 for ; Mon, 2 Aug 2010 04:03:27 -0400 In-Reply-To: <20100802075838.GL24773@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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.