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)
- 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. 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 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.
Regards,
Anthony Liguori
--
Gleb.
