From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl-Daniel Hailfinger Subject: Re: [Bochs-developers] [Qemu-devel] [PATCH 0/3] Add BIOS splash image support Date: Wed, 17 Dec 2008 17:21:47 +0100 Message-ID: <4949271B.7030105@gmx.net> References: <1229440810-12394-1-git-send-email-Laurent.Vivier@bull.net> <49480F6D.2010302@codemonkey.ws> <1229464268.26715.12.camel@frecb07144> <4948435D.1090204@gmx.net> <1229519355.4116.6.camel@frecb07144> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: qemu-devel@nongnu.org, bochs developers , kvm developers To: Laurent Vivier Return-path: Received: from mail.gmx.net ([213.165.64.20]:37301 "HELO mail.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751337AbYLQQVy (ORCPT ); Wed, 17 Dec 2008 11:21:54 -0500 In-Reply-To: <1229519355.4116.6.camel@frecb07144> Sender: kvm-owner@vger.kernel.org List-ID: On 17.12.2008 14:09, Laurent Vivier wrote: > Le mercredi 17 d=C3=A9cembre 2008 =C3=A0 01:10 +0100, Carl-Daniel Hai= lfinger a > =C3=A9crit : > =20 >> On 16.12.2008 22:51, Laurent Vivier wrote: >> =20 >>> Le mardi 16 d=C3=A9cembre 2008 =C3=A0 22:46 +0200, Blue Swirl a =C3= =A9crit : >>> =20 >>> =20 >>>> On 12/16/08, Anthony Liguori wrote: >>>> =20 >>>> =20 >>>>> Blue Swirl wrote: >>>>> =20 >>>>> =20 >>> =20 >>> =20 >>>>>> The control channel may still be needed. >>>>>> >>>>>> Alternatively the BIOS could load the image and fade parameters = from a >>>>>> new ROM or from the configuration device and draw it to screen. = This >>>>>> would need some PNG support to BIOS, or that the image stored in= raw >>>>>> form. >>>>>> >>>>>> >>>>>> =20 >>>>>> =20 >>>>> Yeah, having QEMU render to the VGA directly is a bit ugly. It = would be >>>>> nicer if the BIOS actually rendered the image but I'm not sure I = think we >>>>> should reject the patch just because it doesn't. >>>>> =20 >>>>> =20 >>>> Actually this way the image can be in full color even if the emula= ted >>>> device was an EGA in text mode. >>>> =20 >>>> =20 >>> And you can provide the image name on the command line, and complex= ity >>> is in Qemu, not in BIOS. >>> =20 >>> =20 >> If one of the goals of QEMU is to be somewhat similar to hardware, t= his >> should be done in the BIOS. >> =20 > > A lot of things in Qemu are already not similar to hardware: virtio, > firmware configuration device, instruction timing... > > =20 >> What happens if the BIOS provides a splash screen? Will it override = the >> QEMU splash screen? >> =20 > > Yes. The BIOS asks Qemu to display the image... or not. > =20 What happens if you run a native BIOS/EFI/whatever for the hardware emulated in QEMU? Some people try to do exactly that. >>> But in fact, my first idea was to read the image data from the >>> configuration device (which is always possible with LOGO_CMD_OFFSET= ), >>> but when I saw how it has been done in VirtualBox, I though it was = a >>> good idea. >>> =20 >>> =20 >> Modern x86 BIOSes read the splash screen from the BIOS ROM and the >> settings from NVRAM (sometimes the BIOS ROM is used for that as well= by >> reflashing a sector of the ROM on every boot). >> =20 > > A BIOS, by definition, is not modern... ;-) > =20 Agreed. > (Openfirmware is...) > =20 Even EFI is more modern than OpenFirmware. However, the most important question here is how you quantify modernness ;-) Speaking as a coreboot (really modern x86 firmware) developer, I'd like to keep the number of workarounds for QEMU hardware quirks to a minimum= =2E Regards, Carl-Daniel --=20 http://www.hailfinger.org/ From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LCz9p-0002xp-Mj for qemu-devel@nongnu.org; Wed, 17 Dec 2008 11:21:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LCz9o-0002xX-Al for qemu-devel@nongnu.org; Wed, 17 Dec 2008 11:21:57 -0500 Received: from [199.232.76.173] (port=41245 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCz9o-0002xN-5T for qemu-devel@nongnu.org; Wed, 17 Dec 2008 11:21:56 -0500 Received: from mail.gmx.net ([213.165.64.20]:49057) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1LCz9n-0007yf-3J for qemu-devel@nongnu.org; Wed, 17 Dec 2008 11:21:55 -0500 Message-ID: <4949271B.7030105@gmx.net> Date: Wed, 17 Dec 2008 17:21:47 +0100 From: Carl-Daniel Hailfinger MIME-Version: 1.0 Subject: Re: [Bochs-developers] [Qemu-devel] [PATCH 0/3] Add BIOS splash image support References: <1229440810-12394-1-git-send-email-Laurent.Vivier@bull.net> <49480F6D.2010302@codemonkey.ws> <1229464268.26715.12.camel@frecb07144> <4948435D.1090204@gmx.net> <1229519355.4116.6.camel@frecb07144> In-Reply-To: <1229519355.4116.6.camel@frecb07144> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Vivier Cc: bochs developers , qemu-devel@nongnu.org, kvm developers On 17.12.2008 14:09, Laurent Vivier wrote: > Le mercredi 17 décembre 2008 à 01:10 +0100, Carl-Daniel Hailfinger a > écrit : > >> On 16.12.2008 22:51, Laurent Vivier wrote: >> >>> Le mardi 16 décembre 2008 à 22:46 +0200, Blue Swirl a écrit : >>> >>> >>>> On 12/16/08, Anthony Liguori wrote: >>>> >>>> >>>>> Blue Swirl wrote: >>>>> >>>>> >>> >>> >>>>>> The control channel may still be needed. >>>>>> >>>>>> Alternatively the BIOS could load the image and fade parameters from a >>>>>> new ROM or from the configuration device and draw it to screen. This >>>>>> would need some PNG support to BIOS, or that the image stored in raw >>>>>> form. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Yeah, having QEMU render to the VGA directly is a bit ugly. It would be >>>>> nicer if the BIOS actually rendered the image but I'm not sure I think we >>>>> should reject the patch just because it doesn't. >>>>> >>>>> >>>> Actually this way the image can be in full color even if the emulated >>>> device was an EGA in text mode. >>>> >>>> >>> And you can provide the image name on the command line, and complexity >>> is in Qemu, not in BIOS. >>> >>> >> If one of the goals of QEMU is to be somewhat similar to hardware, this >> should be done in the BIOS. >> > > A lot of things in Qemu are already not similar to hardware: virtio, > firmware configuration device, instruction timing... > > >> What happens if the BIOS provides a splash screen? Will it override the >> QEMU splash screen? >> > > Yes. The BIOS asks Qemu to display the image... or not. > What happens if you run a native BIOS/EFI/whatever for the hardware emulated in QEMU? Some people try to do exactly that. >>> But in fact, my first idea was to read the image data from the >>> configuration device (which is always possible with LOGO_CMD_OFFSET), >>> but when I saw how it has been done in VirtualBox, I though it was a >>> good idea. >>> >>> >> Modern x86 BIOSes read the splash screen from the BIOS ROM and the >> settings from NVRAM (sometimes the BIOS ROM is used for that as well by >> reflashing a sector of the ROM on every boot). >> > > A BIOS, by definition, is not modern... ;-) > Agreed. > (Openfirmware is...) > Even EFI is more modern than OpenFirmware. However, the most important question here is how you quantify modernness ;-) Speaking as a coreboot (really modern x86 firmware) developer, I'd like to keep the number of workarounds for QEMU hardware quirks to a minimum. Regards, Carl-Daniel -- http://www.hailfinger.org/