On real hardware it is shared between BIOS and the OS, actually. "Gleb Natapov" <g...@redhat.com> wrote:
>On Tue, Oct 12, 2010 at 09:33:16AM -0700, H. Peter Anvin wrote: >> On 10/12/2010 01:01 AM, Gleb Natapov wrote: >> > On Mon, Oct 11, 2010 at 02:15:26PM -0700, H. Peter Anvin wrote: >> >>> I don't disagree. >> >>> >> >>> I think the best thing to do is to let SeaBIOS create a boot order table >> >>> that contains descriptive information and then advertise that to QEMU. >> >>> >> >>> QEMU can then try to associate the list of bootable devices with it's >> >>> own set of devices and select a preferred order that it can then give >> >>> back to SeaBIOS. SeaBIOS can then present that list to the user for >> >>> additional refinement. >> >> >> >> Really, this kind of comes down to having a data structure that anything >> >> (Qemu, SeaBIOS and if needed the guest OS) can read and modify as needed. >> >> >> > But then QEMU and seabios will have to have shared storage they can >> > both write too. And this shared storage is part of VM now so you need >> > to carry it around when you move your VM elsewhere. >> > >> >> Yes, and it's part of real hardware, too. It's usually called "the >> CMOS", short for CMOS RAM. >> >On real hardware it is not shared between HW and bios. It is >written/read only by BIOS. In qemu it is not persistent and generated >for each qemu invocation. Previously it was used to pass config params >from qemu to a bios (and some legacy params are still passed that way), >but we moved to better interface for that (firmware config). > >-- > Gleb. -- Sent from my mobile phone. Please pardon any lack of formatting.
