From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52449) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr7Pt-0007ZW-8x for qemu-devel@nongnu.org; Wed, 19 Nov 2014 10:43:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr7Pn-00018V-5E for qemu-devel@nongnu.org; Wed, 19 Nov 2014 10:43:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36311) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr7Pm-00018L-SV for qemu-devel@nongnu.org; Wed, 19 Nov 2014 10:43:31 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAJFhTWS023458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 19 Nov 2014 10:43:30 -0500 Date: Wed, 19 Nov 2014 17:43:26 +0200 From: "Michael S. Tsirkin" Message-ID: <20141119154326.GB28563@redhat.com> References: <20141119093320.GA26119@redhat.com> <87d28jo5yp.fsf@elfo.elfo> <20141119102136.GC26395@redhat.com> <878uj7o4ec.fsf@elfo.elfo> <20141119132851.GA27435@redhat.com> <87vbmbmhaj.fsf@elfo.elfo> <546CA051.4050803@redhat.com> <87egszmgn4.fsf@elfo.elfo> <546CA4F5.2080202@redhat.com> <871tozmfvs.fsf@elfo.elfo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871tozmfvs.fsf@elfo.elfo> Subject: Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: Paolo Bonzini , qemu-devel@nongnu.org, dgilbert@redhat.com On Wed, Nov 19, 2014 at 03:20:07PM +0100, Juan Quintela wrote: > Paolo Bonzini wrote: > > On 19/11/2014 15:03, Juan Quintela wrote: > >> Paolo Bonzini wrote: > >>> On 19/11/2014 14:49, Juan Quintela wrote: > >>>>>> Real hardware lets users update firmware and so should virtual hardware. > >>>> But you can hibernate your laptop, update the firmware, and reboot? > >>>> Where the change can be anyting, like moving from traditional BIOS to > >>>> UEFI? > >>> > >>> Wait wait wait. I totally cannot follow. What would be the equivalent > >>> in QEMU? > >> > >> qemu-2.0 -M pc-2.0 > >> > >> migrate to disk/s3/s4 > >> > >> upgrade qemu > >> > >> qemu-2.2 -M pc-2.0 > >> > >> try interesting variation of s3/s4/migration to disk. Migration to disk > >> should work (we migrate BIOS ROM blocks, enphasis on ROM), s3 perhaps > >> (machine needs to be saved to disk), s4 ..... depends how it ends being > >> done. > > > > Ok, got it. S3 + migrate to disk should work. > > > > S4 probably would work, but I think it would work on a real system too > > as long as you update software and not hardware (e.g. changing the > > motherboard would change the MAC address of the on-board NIC, for example). > > > > Consider the similar case on real hardware: > > > > boot > > update microcode RPM > > s4 > > turn on > > > > CPU microcode is installed early by the kernel, before looking for a > > hibernation image to resume from, so the CPU microcode after resume from > > S4 is different from the microcode at the time you suspended to disk. > > This probably would work. > > I am not an expert of cpu microcode, but I would assume that changes > there tend to be minimal, no? And anyways, I wouldn't expect to > introduce/remove features like NX (i.e. visible by the guest) on a > microcode update? > > Later, Juan. > > > Paolo Not added mostly because there's no point: CPU vendors would much rather sell you a new CPU :) Features could be removed because of some errata? -- MST