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 <[email protected]> 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/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
