From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KXdF7-0006ww-5U for qemu-devel@nongnu.org; Mon, 25 Aug 2008 10:40:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KXdF6-0006vh-FB for qemu-devel@nongnu.org; Mon, 25 Aug 2008 10:40:28 -0400 Received: from [199.232.76.173] (port=53113 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KXdF6-0006vQ-6R for qemu-devel@nongnu.org; Mon, 25 Aug 2008 10:40:28 -0400 Received: from il.qumranet.com ([212.179.150.194]:24379) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KXdF5-0007Fx-Lr for qemu-devel@nongnu.org; Mon, 25 Aug 2008 10:40:28 -0400 Date: Mon, 25 Aug 2008 17:40:26 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH v2 1/6] Use IO port for qemu<->guest BIOS communication. Message-ID: <20080825144026.GQ6192@minantech.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48B2C0A1.7040309@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 Cc: Blue Swirl On Mon, Aug 25, 2008 at 09:24:33AM -0500, Anthony Liguori wrote: > Gleb Natapov wrote: >> Use PIO to get configuration info between qemu process and guest BIOS. >> >> Signed-off-by: Gleb Natapov >> --- >> >> hw/pc.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 59 insertions(+), 0 deletions(-) >> >> diff --git a/hw/pc.c b/hw/pc.c >> index 213ead8..8caa48f 100644 >> --- a/hw/pc.c >> +++ b/hw/pc.c >> @@ -44,6 +44,7 @@ >> /* Leave a chunk of memory at the top of RAM for the BIOS ACPI >> tables. */ >> #define ACPI_DATA_SIZE 0x10000 >> +#define BIOS_CFG_IOPORT 0x1234 >> #define MAX_IDE_BUS 2 >> @@ -53,6 +54,26 @@ static PITState *pit; >> static IOAPICState *ioapic; >> static PCIDevice *i440fx_state; >> +typedef struct _BIOSCfgEntry { >> + uint16_t len; >> + uint8_t *data; >> +} BIOSCfgEntry; >> > > So why aren't we using the ROM mechanism suggested by Blue Swirl? > Unless we're switching other firmwares to use this mechanism, I think it > would be better to have a single QEMU<->firmware interface that we could > support for all architectures. > There was a long discussion about this. Have you read it already? 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. Note that all current users of firmware ABI uses memory mapped access to firmware structure and you proposed to use port IO for PC. -- Gleb.