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 12:08:29 +0300 Message-ID: <4C568B0D.4020304@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> <20100802090537.GO24773@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]:10525 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753264Ab0HBJIb (ORCPT ); Mon, 2 Aug 2010 05:08:31 -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 o7298VCB003569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 2 Aug 2010 05:08:31 -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 o7298UWV032628 for ; Mon, 2 Aug 2010 05:08:30 -0400 In-Reply-To: <20100802090537.GO24773@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 08/02/2010 12:05 PM, Gleb Natapov wrote: >>> >>> 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). That's fine, device assignment is specialized enough. I'm more worried about everyday workloads. >>>> 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. This happens before the vapic is detected. In fact, this particular port is during option rom initialization; I don't think it's in big real mode. -- error compiling committee.c: too many arguments to function