From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KvHOy-0008Bn-7G for qemu-devel@nongnu.org; Wed, 29 Oct 2008 16:12:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KvHOw-00088u-96 for qemu-devel@nongnu.org; Wed, 29 Oct 2008 16:12:23 -0400 Received: from [199.232.76.173] (port=46486 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KvHOv-00088k-W0 for qemu-devel@nongnu.org; Wed, 29 Oct 2008 16:12:22 -0400 Received: from mail-gx0-f17.google.com ([209.85.217.17]:59856) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KvHOu-0002de-Ny for qemu-devel@nongnu.org; Wed, 29 Oct 2008 16:12:21 -0400 Received: by gxk10 with SMTP id 10so249gxk.4 for ; Wed, 29 Oct 2008 13:12:18 -0700 (PDT) Message-ID: Date: Wed, 29 Oct 2008 21:13:37 +0200 From: "Blue Swirl" Subject: Re: [Qemu-devel] Re: [PATCH 3/3] Add KVM support to QEMU In-Reply-To: <49086E96.80809@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 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> <49086E96.80809@redhat.com> Reply-To: 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 , hollis@alumni.cmu.edu, Gerd Hoffmann , kvm-devel On 10/29/08, Avi Kivity wrote: > 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 It should be possible to avoid these, just use a qemu_irq for per-CPU interrupt lines and halt signals. > vmport -- bad ABI requires access to registers Ugly. Maybe there could be two parts, one in pc.c which registers the ioport and checks EAX/ECX, maybe using a CPU specific helper, and second part, generic port in vmport.c, which does not know about CPU state. I don't know if this would solve the original atomicity problem, though.