qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 2/5] exec: qemu_ram_alloc_device, qemu_ram_resize
Date: Wed, 19 Nov 2014 15:11:01 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0


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.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]