From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KvBjw-0001xb-VW for qemu-devel@nongnu.org; Wed, 29 Oct 2008 10:09:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KvBjw-0001wu-3y for qemu-devel@nongnu.org; Wed, 29 Oct 2008 10:09:40 -0400 Received: from [199.232.76.173] (port=40658 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KvBjv-0001wr-VH for qemu-devel@nongnu.org; Wed, 29 Oct 2008 10:09:39 -0400 Received: from mx2.redhat.com ([66.187.237.31]:45630) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KvBjv-0002LC-9S for qemu-devel@nongnu.org; Wed, 29 Oct 2008 10:09:39 -0400 Message-ID: <49086E96.80809@redhat.com> Date: Wed, 29 Oct 2008 16:09:26 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 3/3] Add KVM support to QEMU References: <1225224814-9875-1-git-send-email-aliguori@us.ibm.com> <1225224814-9875-2-git-send-email-aliguori@us.ibm.com> <1225224814-9875-3-git-send-email-aliguori@us.ibm.com> <49078707.5000109@redhat.com> <49078955.2090109@codemonkey.ws> <5d6222a80810281604g39708040kf710725dce6413dd@mail.gmail.com> <4907A1FA.2060106@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: hollis@alumni.cmu.edu Cc: Glauber Costa , Glauber Costa , qemu-devel@nongnu.org, kvm-devel , Gerd Hoffmann Hollis Blanchard wrote: > On Tue, Oct 28, 2008 at 6:36 PM, Anthony Liguori wrote: > >> Something I was thinking about this morning, and I think the first place >> where we'll definitely need a hook, is how to deal with >> kvm_load_registers(). I think there's overlap between KVM and the IO thread >> here. >> >> There are two reasons (I can think of) that most of the device model code >> can't run in conjunction with TCG. The first is that TCG may modify >> CPUState in a non-atomic way. The device model may need to access CPUState >> although there are very few places that it does. >> > > Out of curiosity, where are those places? > local apic -- needs to access interrupt disable flag acpi sleep -- halts the current processor, so tied to cpustate vmport -- bad ABI requires access to registers -- error compiling committee.c: too many arguments to function