From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMs5C-0003TU-0P for qemu-devel@nongnu.org; Mon, 21 Dec 2009 18:54:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMs56-0003Rk-VI for qemu-devel@nongnu.org; Mon, 21 Dec 2009 18:54:33 -0500 Received: from [199.232.76.173] (port=42727 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMs56-0003Rh-MZ for qemu-devel@nongnu.org; Mon, 21 Dec 2009 18:54:28 -0500 Received: from mail-iw0-f197.google.com ([209.85.223.197]:32840) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMs56-00079w-CP for qemu-devel@nongnu.org; Mon, 21 Dec 2009 18:54:28 -0500 Received: by iwn35 with SMTP id 35so3851086iwn.4 for ; Mon, 21 Dec 2009 15:54:27 -0800 (PST) Message-ID: <4B300AAE.7040009@codemonkey.ws> Date: Mon, 21 Dec 2009 17:54:22 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul. References: <4B2E453A.3060004@codemonkey.ws> <20091220155201.GP4490@redhat.com> <4B2E6364.9060903@codemonkey.ws> <20091221015948.GA23556@morn.localdomain> <20091221073204.GS4490@redhat.com> <4B2FA518.7000905@codemonkey.ws> <20091221164351.GW4490@redhat.com> <4B2FAFB4.8050102@codemonkey.ws> <20091221174312.GD21163@redhat.com> <4B2FC8C6.2000408@codemonkey.ws> <20091221194359.GF21163@redhat.com> In-Reply-To: <20091221194359.GF21163@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: Kevin O'Connor , Gerd Hoffmann , qemu-devel@nongnu.org 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. >