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

[Steven Sistare]

On 6/24/2021 11:05 AM, Steven Sistare wrote:
> 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.

I just posted V4 of the patch series, refactoring reboot mode into the first 4 
patches.

- Steve