[Top][All Lists]

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

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

From: Dr. David Alan Gilbert
Subject: Re: [PATCH V3 00/22] Live Update [reboot]
Date: Tue, 15 Jun 2021 20:14:30 +0100
User-agent: Mutt/2.0.7 (2021-05-04)

* 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.


> - Steve
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

reply via email to

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