On Tue, Oct 12, 2010 at 10:35:51AM -0700, H. Peter Anvin wrote: > On real hardware it is shared between BIOS and the OS, actually. > Guest OS can write in qemu CMOS too. But what is it useful for? Most of its content is not standard AFAIK.
> "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. -- Gleb.