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:24:14 +0300 Message-ID: <4C5680AE.4050907@redhat.com> References: <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> <4C567BCE.50106@redhat.com> <20100802081729.GM24773@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]:24030 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752342Ab0HBIYQ (ORCPT ); Mon, 2 Aug 2010 04:24:16 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o728OFZT030196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 2 Aug 2010 04:24:15 -0400 Received: from cleopatra.tlv.redhat.com (cleopatra.tlv.redhat.com [10.35.255.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o728OEOv021497 for ; Mon, 2 Aug 2010 04:24:15 -0400 In-Reply-To: <20100802081729.GM24773@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 08/02/2010 11:17 AM, Gleb Natapov wrote: > >> We don't know what they'll do. API stability means we only change >> things to fix bugs. > Is this API documented? Do we guaranty somewhere anywhere that rip during io > point past the instruction? I think it should be documented that cpu > state cannot be accessed during io emulation. The user code was written before the documentation. > And we can preserve old > behaviour for old guests by disabling e_i_g_s for them. But the user will see a crash first and report a bug. That's not the experience we want users to have. >> Windows XP does use big real mode (I think unintentionally, some >> segment registers aren't cleared). > How it works now then? If it works because Windows XP doesn't > realize it runs in big real mode so it doesn't actually access past > segment limit why starting emulating it? IIRC it leaves fs and gs pointing to large segments, but it never accesses them. Since we can't tell whether the guest will use those segments, we can't avoid emulating big real mode. Right now most things work, but that's because we hacked around everything. > Boot will take much more time > without any gain. The gain is correctness. > And finally does it access TPR while running in big real > mode? I don't think so. >>> What do you call "optimization"? e_i_g_s=1? Isn't it the same as I proposed >>> then? >> The optimization is your patch. >> > I think there is misunderstanding here. My patch does not change > anything in this regards. If io exit to userspace is done from emulator > rip will point to io instruction with or without my patch and it was always > this way. In that case the whole thing is moot. When we set eigs=1 we'll have to test Windows XP and hack around it if needed. -- error compiling committee.c: too many arguments to function