[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