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 12:05:37 +0300 Message-ID: <20100802090537.GO24773@redhat.com> References: <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> <20100802083449.GN24773@redhat.com> <4C5687E2.8040508@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]:37939 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751172Ab0HBJFi (ORCPT ); Mon, 2 Aug 2010 05:05:38 -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 o7295c6d032161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 2 Aug 2010 05:05:38 -0400 Content-Disposition: inline In-Reply-To: <4C5687E2.8040508@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Aug 02, 2010 at 11:54:58AM +0300, Avi Kivity wrote: > On 08/02/2010 11:34 AM, Gleb Natapov wrote: > >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. > > What guests did we break? > The one that uses device assignment with old qemu-kvm userspace. Old qemu-kvm copied assigned card's ROM into memory and made it read only (mprotect(RO)) to get MMIO exists on it. Even older device assignment code unmapped one page in the middle of a slot to get mmio exist if the page is accessed (and this breaks if mmap decides to mmap something else there). > >>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. > > That code is in userspace. If we can change userspace, the whole > problem is gone. Userspace calls kvm_enable_vapic() to let kernel know that vapic is enabled. -- Gleb.