qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH V3 07/22] cpr


From: Stefan Hajnoczi
Subject: Re: [PATCH V3 07/22] cpr
Date: Fri, 14 May 2021 12:28:35 +0100

On Thu, May 13, 2021 at 04:21:02PM -0400, Steven Sistare wrote:
> On 5/12/2021 12:19 PM, Stefan Hajnoczi wrote:
> > On Fri, May 07, 2021 at 05:25:05AM -0700, Steve Sistare wrote:
> >> To use the restart mode, qemu must be started with the memfd-alloc machine
> >> option.  The memfd's are saved to the environment and kept open across 
> >> exec,
> >> after which they are found from the environment and re-mmap'd.  Hence guest
> >> ram is preserved in place, albeit with new virtual addresses in the qemu
> >> process.  The caller resumes the guest by calling cprload, which loads
> >> state from the file.  If the VM was running at cprsave time, then VM
> >> execution resumes.  cprsave supports any type of guest image and block
> >> device, but the caller must not modify guest block devices between cprsave
> >> and cprload.
> > 
> > Does QEMU's existing -object memory-backend-file on tmpfs or hugetlbfs
> > achieve the same thing?
> 
> Not quite.  Various secondary anonymous memory objects are allocated via 
> ram_block_add
> and must be preserved, such as these on x86_64.  
>   vga.vram
>   pc.ram
>   pc.bios
>   pc.rom
>   vga.rom
>   rom@etc/acpi/tables
>   rom@etc/table-loader
>   rom@etc/acpi/rsdp
> 
> Even the read-only areas must be preserved rather than recreated from files 
> in the updated
> qemu, as their contents may have changed.

Migration knows how to save/load these RAM blocks. Only pc.ram is
significant in size so I'm not sure it's worth special-casing the
others?

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

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