From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KXgmg-0000Df-8c for qemu-devel@nongnu.org; Mon, 25 Aug 2008 14:27:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KXgme-0000DI-QA for qemu-devel@nongnu.org; Mon, 25 Aug 2008 14:27:21 -0400 Received: from [199.232.76.173] (port=50660 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KXgme-0000DF-KL for qemu-devel@nongnu.org; Mon, 25 Aug 2008 14:27:20 -0400 Received: from mail-gx0-f19.google.com ([209.85.217.19]:53002) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KXgme-0004cC-U0 for qemu-devel@nongnu.org; Mon, 25 Aug 2008 14:27:21 -0400 Received: by gxk12 with SMTP id 12so2483480gxk.10 for ; Mon, 25 Aug 2008 11:27:19 -0700 (PDT) Message-ID: Date: Mon, 25 Aug 2008 21:27:18 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] [PATCH v2 1/6] Use IO port for qemu<->guest BIOS communication. In-Reply-To: <48B2F373.1020606@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> <48B2F373.1020606@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: Anthony Liguori Cc: Gleb Natapov , qemu-devel@nongnu.org On 8/25/08, Anthony Liguori wrote: > 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. I could switch Sparc to something like this, if the goal is that it will be used by all targets. There should be a .h file which lists the keys and which can be included from C and asm, like current firmware_abi.h. I'd define an offset (0x8000?) for architecture-specific keys which need not be in the same .h file.