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

[Juan Quintela]

Paolo Bonzini <address@hidden> wrote:
> On 19/11/2014 15:03, Juan Quintela wrote:
>> Paolo Bonzini <address@hidden> 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