From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K8tZv-00085X-99 for qemu-devel@nongnu.org; Wed, 18 Jun 2008 05:03:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K8tZs-00084Z-VY for qemu-devel@nongnu.org; Wed, 18 Jun 2008 05:03:42 -0400 Received: from [199.232.76.173] (port=47568 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K8tZs-00084O-D4 for qemu-devel@nongnu.org; Wed, 18 Jun 2008 05:03:40 -0400 Received: from lizzard.sbs.de ([194.138.37.39]:19450) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K8tZr-0000aA-Pi for qemu-devel@nongnu.org; Wed, 18 Jun 2008 05:03:40 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id m5I90aDt023450 for ; Wed, 18 Jun 2008 11:00:36 +0200 Received: from [192.168.1.100] ([139.21.92.145]) by mail2.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id m5I90Zsr032257 for ; Wed, 18 Jun 2008 11:00:36 +0200 Message-ID: <4858CEB2.2060009@siemens.com> Date: Wed, 18 Jun 2008 11:00:34 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <48576EBE.2030506@siemens.com> <485831C4.4000107@bellard.org> In-Reply-To: <485831C4.4000107@bellard.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: loadvm and APIC 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 Fabrice Bellard wrote: > malc wrote: >> On Tue, 17 Jun 2008, Jan Kiszka wrote: >> >>> malc wrote: >>>> Here's the scenario: >>>> >> [..snip..] >> >>> That is basically >>> http://permalink.gmane.org/gmane.comp.emulators.qemu/26215, which I >>> would prefer. >> Yes, i never paid enough attention to that patch, and it does indeed >> look better. > > No. This is a hack which does not fix the real problem. At least saving > and restoring "interrupt_pending" would bring us closer to a better > solution. No problem, patch for archs that care about cpu state saving is on the way. I would just have appreciated receiving some indication how you'd like to see that bug being addressed earlier. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux