From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KvBSE-0000oF-Q6 for qemu-devel@nongnu.org; Wed, 29 Oct 2008 09:51:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KvBSD-0000o0-BD for qemu-devel@nongnu.org; Wed, 29 Oct 2008 09:51:22 -0400 Received: from [199.232.76.173] (port=38034 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KvBSD-0000nn-6i for qemu-devel@nongnu.org; Wed, 29 Oct 2008 09:51:21 -0400 Received: from yx-out-1718.google.com ([74.125.44.156]:33132) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KvBSC-0003jC-By for qemu-devel@nongnu.org; Wed, 29 Oct 2008 09:51:20 -0400 Received: by yx-out-1718.google.com with SMTP id 3so736366yxi.82 for ; Wed, 29 Oct 2008 06:51:19 -0700 (PDT) Message-ID: Date: Wed, 29 Oct 2008 08:51:18 -0500 From: "Hollis Blanchard" Sender: slightlyunconventional@gmail.com Subject: Re: [Qemu-devel] Re: [PATCH 3/3] Add KVM support to QEMU In-Reply-To: <4907A1FA.2060106@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> Reply-To: hollis@alumni.cmu.edu, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Glauber Costa , Glauber Costa , Avi Kivity , kvm-devel , Gerd Hoffmann 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? -Hollis