From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KXFHO-00044V-Hw for qemu-devel@nongnu.org; Sun, 24 Aug 2008 09:05:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KXFHM-00041Y-Uf for qemu-devel@nongnu.org; Sun, 24 Aug 2008 09:05:14 -0400 Received: from [199.232.76.173] (port=53051 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KXFHM-00041P-LL for qemu-devel@nongnu.org; Sun, 24 Aug 2008 09:05:12 -0400 Received: from il.qumranet.com ([212.179.150.194]:25300) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KXFHL-0007l7-Tv for qemu-devel@nongnu.org; Sun, 24 Aug 2008 09:05:12 -0400 Received: from gleb-debian.qumranet.com (gleb-debian.qumranet.com.qumranet.com [172.16.15.143]) by il.qumranet.com (Postfix) with ESMTP id B23DF250310 for ; Sun, 24 Aug 2008 16:05:10 +0300 (IDT) Date: Sun, 24 Aug 2008 16:05:10 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH 0/6] Add UUID command-line option Message-ID: <20080824130510.GC6192@minantech.com> References: <20080824113258.5652.92531.stgit@gleb-debian.qumranet.com.qumranet.com> <20080824122423.GA6192@minantech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Sun, Aug 24, 2008 at 03:45:51PM +0300, Blue Swirl wrote: > > It is hard enough to change interface between qemu and bochs BIOS. How > > complex it will be to simultaneously change interface for several boot > > loaders. > > This is because no Qemu developer has commit rights to Bochs, and > Bochs releases too infrequently. With commit rights, synchronizing a > commit would not be too difficult. And this should be needed only if > the common interface changes incompatibly. > Is this situation going to change? Are Qemu developers has commit rights to other boot loader? BTW we are going to use qemu<->bios channel not only for UUID and cpu frequency, but for number of other things. Adding ACPI tables provided by user for instance (this is needed for Vista OEM installation). > > > UUID is not architecture specific, so it should use the > > > main structure instead if the architecture specific substructure > > > (nvram_arch*). Adding UUID to unused fields will not break anything. > > > > Most info in ohwcfg_v3_t are not needed (or can be obtained by other > > means) by PC BIOS, so there is no point in coping the whole structure > > into BIOS. Of cause BIOS don't have to copy entire ohwcfg_v3_t, but > > For example, Bochs seems to use i440fx registers to determine the > available physical memory. This could be changed to use the > configuration structure instead. It's a matter of taste, but I would > find this an improvement. If by Bochs you mean Bochs BIOS then this is not the case. There are standard CMOS locations where amount of available memory is specified. Qemu initialize those locations and BIOS reads them. I don't think this is going to change since Bochs BIOS is used not only by Qemu. If only Bochs will move to firmware interface too... > > > access only required fields by reading only specific offsets, but then the > > interface will be exactly like the one I proposed with only difference > > that instead of specifying magic value (like 1 for reading UUID in my > > patch series), BIOS will have to specify magic offset (like 0xE0). > > There is no need for a magic offset, ohwcfg_v3_t is designed to be > included even from asm. > The thing is I don't want to copy the whole ROM into BIOS during boot. As far as I see on other platforms ROM is memory mapped, so no copying is required and this was you first proposal, but if we are going to use port IO to access ROM then it will either have to be copied into main memory and then accessed, or only required fields will have to be copied and that mean coping data from magic offsets. -- Gleb.