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" gleb@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.