From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KXgOM-0000t0-0c for qemu-devel@nongnu.org; Mon, 25 Aug 2008 14:02:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KXgOK-0000sT-A9 for qemu-devel@nongnu.org; Mon, 25 Aug 2008 14:02:13 -0400 Received: from [199.232.76.173] (port=58648 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KXgOK-0000sO-0d for qemu-devel@nongnu.org; Mon, 25 Aug 2008 14:02:12 -0400 Received: from wr-out-0506.google.com ([64.233.184.239]:15394) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KXgOJ-00083U-WB for qemu-devel@nongnu.org; Mon, 25 Aug 2008 14:02:12 -0400 Received: by wr-out-0506.google.com with SMTP id c46so1692015wra.18 for ; Mon, 25 Aug 2008 11:02:10 -0700 (PDT) Message-ID: <48B2F373.1020606@codemonkey.ws> Date: Mon, 25 Aug 2008 13:01:23 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v2 1/6] Use IO port for qemu<->guest BIOS communication. References: <20080825095800.18703.30602.stgit@gleb-debian.qumranet.com.qumranet.com> <20080825095805.18703.63202.stgit@gleb-debian.qumranet.com.qumranet.com> <48B2C0A1.7040309@codemonkey.ws> <20080825144026.GQ6192@minantech.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Blue Swirl , Gleb Natapov Blue Swirl wrote: > On 8/25/08, Gleb Natapov wrote: >> >> There was a long discussion about this. Have you read it already? Yes, but it wasn't clear to me that there was a consensus in that discussion. Since the code isn't structured for reuse either, that raised a flag. I think it would be pretty useful to have a standard mechanism that worked across architectures to query QEMU-specific information. >> My reasoning is >> that firmware structure mostly provides information that PC bios doesn't >> need and don't provides info that PC bios needs. Nobody showed what is >> the benefit of using firmware interface for communicating with PC bios >> yet. Because firmware interface contains mostly unneeded info there is >> no point in copying the whole structure into the bios, only specific >> fields will be copied and to do that bios will have to know magic value >> (offset of the field). So just instead of pretending we are using firmware >> interface we can simply define magic values for each parameter we want >> to pass from qemu to bios and use them instead of structure offsets. >> > > This has the advantage that the sizes of the fields are not fixed by > the structure layout. On the other hand, same can be achieved with ROM > by using an index, which lists the offsets and sizes in the beginning > of the ROM for each magic parameter. If some parameter is not used > (for that architecture or because a newer version has suppressed it), > size and index can be zero. > > A more important benefit is in my view that the whole protocol can be > extended, whereas a ROM will always be a ROM. But then taking a > security angle, that could be an advantage too. I don't know which is > more important. > Blue Swirl: What do you think of switching sparc to use a structure more like this? I do prefer a key-value mechanism verses a blob. Even with pure MMIO, the same results could be achieved by treating the MMIO region as registers and using a selector. Regards, Anthony Liguori