From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH 1/2] KVM: x86 emulator: don't update vcpu state if instruction is restarted. Date: Sun, 1 Aug 2010 16:27:14 +0300 Message-ID: <20100801132714.GH24773@redhat.com> References: <20100801082815.GC24773@redhat.com> <4C55364E.9090605@redhat.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: mtosatti@redhat.com, kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:13538 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754382Ab0HAN1P (ORCPT ); Sun, 1 Aug 2010 09:27:15 -0400 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o71DRFws026446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 1 Aug 2010 09:27:15 -0400 Content-Disposition: inline In-Reply-To: <4C556A1D.2050105@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Sun, Aug 01, 2010 at 03:35:41PM +0300, Avi Kivity wrote: > On 08/01/2010 03:23 PM, Gleb Natapov wrote: > >On Sun, Aug 01, 2010 at 03:17:10PM +0300, Avi Kivity wrote: > >> On 08/01/2010 01:53 PM, Gleb Natapov wrote: > >>>>That requires everyone to update, or suffer major breakage. > >>>> > >>>They will suffer major breakage when they update to a kvm that calls to > >>>kvm-tpr-opt.c from emulator anyway. > >>Why? > >> > >Because tpr code will be called with wrong rip. Emulator always updated rip at the end > >of an instruction emulation in writeback stage. > > > > We can change it before switching enabling e_i_g_s by default. > > Break emulator? We can't increment rip for all instructions before emulation since then exception will be injected at incorrect rip. Adding code that rollbacks rip in case of exception will complicate things and exception is not the only reason to keep rip pointed to the instruction. We may want to reenter guest to reexecute it for instance. > >>>So what can we do about it? > >>> > >>Keep the existing behaviour. > >> > >Existing behaviour will cause breakage. > > > > The existing user-visible behaviour. The user doesn't know whether > the emulator is involved or not. > When we are going to enable e_i_g_s by default? May be we have enough time to fix userspace? 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. -- Gleb.