qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.


From: Sebastian Herbszt
Subject: [Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
Date: Tue, 22 Dec 2009 21:50:59 +0100

Anthony Liguori wrote:
On 12/21/2009 01:43 PM, Gleb Natapov wrote:
Please stop thinking so :) Especially about "user driven upgrades".
Why combine disadvantages of vitalization with pain of physical HW
management? Or may be next step will be to require uploading of CPU
microcode to take advantage of KVM/tcg bug fixes?

I think your real argument boils down to that we can be better than real hardware therefore we should. I actually agree with you for 90% of users. Let me summarize where I'm at.

- We are currently horribly broken with respect to how we handle roms particularly with respect to backwards compatibility - We must support running older roms on newer qemu at least within a stable series (because of live migration)
 - We need a mechanism to include roms specific to a machine type
- Probably by default, we want new roms to be used by guests at some well defined time (either first reset or first power-down/start-up)

Start-up sounds good.

- We ought to make all roms live in qemu_ram_alloc()'d memory and we ought to change that api to contain contexts, this will make sure rom live migration works properly.

The best approach I can think of is to introduce an nvram mechanism. A tar file probably work really well. If a user doesn't supply an explicit -nvram, we could create a temporary file and delete it. If the nvram is empty, we populate it with whatever the appropriate roms are for the machine type.

I would also suggest that we support the guest updating roms on its own (through fw_cfg). I can think of a number of reasons for this. For instance, why shouldn't a guest be able to update the gPXE associated with the network card? The code runs entirely in the guest so there's no harm to the host.

You mean the nvram file on the host or in memory? Will there be a size limit?

Allow a guest to do this sort of thing takes pressure off of the management system so particularly in an environment like a cloud, I think this could prove very useful.

It might not be desired and make support efforts harder. Could have security
implications too.

It could be possible to add an option to -nvram to make it re-read roms from disk every reboot. I really think this is a bad idea though, I'd like to hear more people comment on it but it's certainly technically feasible.

- Sebastian





reply via email to

[Prev in Thread] Current Thread [Next in Thread]