From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KXEyi-0003e0-3b for qemu-devel@nongnu.org; Sun, 24 Aug 2008 08:45:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KXEyf-0003dc-UK for qemu-devel@nongnu.org; Sun, 24 Aug 2008 08:45:55 -0400 Received: from [199.232.76.173] (port=56106 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KXEyf-0003dZ-Nj for qemu-devel@nongnu.org; Sun, 24 Aug 2008 08:45:53 -0400 Received: from wf-out-1314.google.com ([209.85.200.172]:13560) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KXEyf-0004Uq-DA for qemu-devel@nongnu.org; Sun, 24 Aug 2008 08:45:53 -0400 Received: by wf-out-1314.google.com with SMTP id 27so1462755wfd.4 for ; Sun, 24 Aug 2008 05:45:52 -0700 (PDT) Message-ID: Date: Sun, 24 Aug 2008 15:45:51 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] [PATCH 0/6] Add UUID command-line option In-Reply-To: <20080824122423.GA6192@minantech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080824113258.5652.92531.stgit@gleb-debian.qumranet.com.qumranet.com> <20080824122423.GA6192@minantech.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 On 8/24/08, Gleb Natapov wrote: > On Sun, Aug 24, 2008 at 03:01:22PM +0300, Blue Swirl wrote: > > On 8/24/08, Gleb Natapov wrote: > > > Hello, > > > > > > This is one more try to push this patch series into qemu. This time > > > I don't use vmport interface. Instead I implemented simple communication > > > channel between qemu and BIOS using IO port. I decided not to use > > > firmware interface since current users of the interface may depend on > > > exact structure layout, so it doesn't look like a good idea to add > > > arbitrary fields there. Also I don't want to copy the whole ROM into BIOS > > > just to access one field of it. IO channel is implemented by the first > > > patch of the series. Patches 2-5 implement UUID related stuff. Patch 6 > > > passes host CPU frequency to fill in SM BIOS table. > > > > > > Please comment. > > > > I disagree about not using the firmware interface. The structure can > > be extended and even new versions defined, all structure users are > > open source. > > 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. > > 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. > 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.