Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Paolo Bonzini (pbonzini@redhat.com) wrote:
> 
> 
> On 19/11/2014 15:03, Juan Quintela wrote:
> > Paolo Bonzini <pbonzini@redhat.com> 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.

You mean, unless for example, someone had disabled a CPU feature in the
new microcode?

Dave

> 
> Paolo
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK