[Top][All Lists]

[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: Thu, 24 Jun 2021 11:05:22 -0400
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

On 6/15/2021 3:14 PM, Dr. David Alan Gilbert wrote:
> * Steven Sistare (steven.sistare@oracle.com) wrote:
>> 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
> Could you split the 'reboot' part of separately, then we can review
> that and perhaps get it in first? It should be a relatively small patch
> set - it'll get things moving in the right direction.
> The guest-suspend-ram stuff seems reasonable as an idea; lets just try
> and avoid doing it all via environment variables though; make it proper
> command line options.

How about I delete reboot mode and the mode argument instead.  Having two modes 
is causing no 
end of confusion, and my primary business need is for restart mode.

- Steve

reply via email to

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