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: Mon, 2 Aug 2010 11:34:49 +0300 Message-ID: <20100802083449.GN24773@redhat.com> References: <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> <4C5680AE.4050907@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]:40510 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752555Ab0HBIev (ORCPT ); Mon, 2 Aug 2010 04:34:51 -0400 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o728YoZo030775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 2 Aug 2010 04:34:50 -0400 Content-Disposition: inline In-Reply-To: <4C5680AE.4050907@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Aug 02, 2010 at 11:24:14AM +0300, Avi Kivity wrote: > 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. > We did it with unmapped pages in the middles of the slot recently. > >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. Definitely. That is why I propose enabling e_i_g_s only if qemu acknowledge that it can use it properly. > > >>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. > We have logic in TPR patching code that tries to detect WindowsXP guest and if XP is detected it enables vapic. We can disable e_i_g_s if vapic is enabled. > >Boot will take much more time > >without any gain. > > The gain is correctness. > Agree. Worthy goal. > >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 -- Gleb.