qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH V3 00/22] Live Update [reboot]


From: Steven Sistare
Subject: Re: [PATCH V3 00/22] Live Update [reboot]
Date: Fri, 21 May 2021 10:55:59 -0400
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1

On 5/20/2021 9:00 AM, Dr. David Alan Gilbert wrote:
> Hi Steven,
>   I'd like to split the discussion into reboot and restart,
> so I can make sure I understand them individually.
> 
> So reboot mode;
> Can you explain which parts of this series are needed for reboot mode;
> I've managed to do a kexec based reboot on qemu with the current qemu -
> albeit with no vfio devices, my current understanding is that for doing
> reboot with vfio we just need some way of getting migrate to send the
> metadata associated with vfio devices if the guest is in S3.
> 
> Is there something I'm missing and which you have in this series?

You are correct, this series has little special code for reboot mode, but it 
does allow
reboot and restart to be handled similarly, which simplifies the management 
layer because 
the same calls are performed for each mode. 

For vfio in reboot mode, prior to sending cprload, the manager sends the 
guest-suspend-ram
command to the qemu guest agent. This flushes requests and brings the guest 
device to a 
reset state, so there is no vfio metadata to save.  Reboot mode does not call 
vfio_cprsave.

There are a few unique patches to support reboot mode.  One is 
qemu_ram_volatile, which
is a sanity check that the writable ram blocks are backed by some form of 
shared memory.
Plus there are a few fragments in the "cpr" patch that handle the suspended 
state that
is induced by guest-suspend-ram.  See qemu_system_start_on_wake_request() and 
instances
of RUN_STATE_SUSPENDED in migration/cpr.c

- Steve



reply via email to

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