From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KcGdM-0007iv-BE for qemu-devel@nongnu.org; Sun, 07 Sep 2008 05:32:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KcGdK-0007fy-IS for qemu-devel@nongnu.org; Sun, 07 Sep 2008 05:32:39 -0400 Received: from [199.232.76.173] (port=38273 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KcGdJ-0007fY-TE for qemu-devel@nongnu.org; Sun, 07 Sep 2008 05:32:38 -0400 Received: from wf-out-1314.google.com ([209.85.200.169]:9024) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KcGdJ-0003qD-Bv for qemu-devel@nongnu.org; Sun, 07 Sep 2008 05:32:37 -0400 Received: by wf-out-1314.google.com with SMTP id 27so1124453wfd.4 for ; Sun, 07 Sep 2008 02:32:36 -0700 (PDT) Message-ID: Date: Sun, 7 Sep 2008 12:32:36 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] [PATCH v2 1/6] Use IO port for qemu<->guest BIOS communication. In-Reply-To: <48C33D89.9000805@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080825095805.18703.63202.stgit@gleb-debian.qumranet.com.qumranet.com> <48B2F373.1020606@codemonkey.ws> <20080826082453.GV6192@minantech.com> <20080827110522.GX6192@minantech.com> <20080828052953.GC9450@minantech.com> <48C33D89.9000805@codemonkey.ws> 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 On 9/7/08, Anthony Liguori wrote: > Gleb Natapov wrote: > > > On Wed, Aug 27, 2008 at 08:10:49PM +0300, Blue Swirl wrote: > > > > > > > On 8/27/08, Gleb Natapov wrote: > > > > > > > > > > On Tue, Aug 26, 2008 at 07:46:20PM +0300, Blue Swirl wrote: > > > > > > Is the patch below what you mean? (not tested, but compiles) > > > > > > > > > > Yes, but I'd still put the code from the .h file and pc.c to a new > .c > > > > > file, only the keys and function prototypes to .h. > > > > > > > > > > > > > Okey, here is updated one (compiled only) > > > > > > > > > > > I added some missing pieces like static/const keywords, device > > > save/load and reset, MMIO and Sparc32/64 support. I also renamed some > > > names for consistency. > > > > > > > > Thanks! I'll rebase my other patches on this and will test it. > > > > > > I think this is missing save/restore support. What happens if you do a > save, move to a different machine, then do a restore, and reboot? The guest > will see a different value IIUC. > > Also, instead of returning 0 on non-linux systems, why not just return some > fixed value? It's no more "wrong" than returning the host clock rate. You commented the wrong patch, but anyway: the clock rate will be saved by configuration device. Loading will be done after hardware has been initializers have been called, so the saved value will be used. The rates may be incorrect anyway. If x86 CPU definitions one day include i386, giving i386 a modern frequency in GHz range can surprise some guests. I think Fabrice didn't like to use floating point arithmetics inside the emulator, but I can't find a reference. Otherwise, a mechanism to present the CPU frequency would be useful, maybe even to other targets.