similar to: [PATCH 0/3] virtio: balloon: cleanups and a fix

Hello, Turns out S3 is not different from S4 for virtio devices: the device is assumed to be reset, so the host and guest state are to be assumed to be out of sync upon resume. We handle the S4 case with exactly the same scenario, so just point the suspend/resume routines to the freeze/restore ones. Once that is done, we also use the PM API's macro to initialise the sleep functions. A

Hello, Turns out S3 is not different from S4 for virtio devices: the device is assumed to be reset, so the host and guest state are to be assumed to be out of sync upon resume. We handle the S4 case with exactly the same scenario, so just point the suspend/resume routines to the freeze/restore ones. Once that is done, we also use the PM API's macro to initialise the sleep functions. A

It has been long since I have sent v3 of the balloon conversion from a kthread to a workqueue. I have gained some more experience with the APIs in the meantime. I hope that you would like the outcome. I have added one more patch that fixes a separate problem with restoring the balloon after the system freeze. I have found this when testing the conversion. Changes against v3: + rebased on

It has been long since I have sent v3 of the balloon conversion from a kthread to a workqueue. I have gained some more experience with the APIs in the meantime. I hope that you would like the outcome. I have added one more patch that fixes a separate problem with restoring the balloon after the system freeze. I have found this when testing the conversion. Changes against v3: + rebased on

On Fri, Dec 04, 2015 at 02:37:50PM +0100, Petr Mladek wrote: > fill_balloon() and leak_balloon() manipulate only a limited number > of pages in one call. This is the reason why remove_common() calls > leak_balloon() in a while cycle. > > remove_common() is called also when the system is being frozen. > But fill_balloon() is called only once when the system is being >

On Fri, Dec 04, 2015 at 02:37:50PM +0100, Petr Mladek wrote: > fill_balloon() and leak_balloon() manipulate only a limited number > of pages in one call. This is the reason why remove_common() calls > leak_balloon() in a while cycle. > > remove_common() is called also when the system is being frozen. > But fill_balloon() is called only once when the system is being >

Hi, These patches add support for S4 to virtio (pci) and all drivers. For each driver, all vqs are removed before hibernation, and then re-created after restore. Some driver-specific uninit and init work is also done in the freeze and restore functions. All the drivers in testing work fine: * virtio-blk is used for the only disk in the VM, IO works fine before and after. 'dd

Hi, These patches add support for S4 to virtio (pci) and all drivers. For each driver, all vqs are removed before hibernation, and then re-created after restore. Some driver-specific uninit and init work is also done in the freeze and restore functions. All the drivers in testing work fine: * virtio-blk is used for the only disk in the VM, IO works fine before and after. 'dd

Hi, These patches add support for S4 to virtio (pci) and all drivers. For each driver, all vqs are removed before hibernation, and then re-created after restore. Some driver-specific uninit and init work is also done in the freeze and restore functions. All the drivers in testing work fine: * virtio-blk is used for the only disk in the VM, IO works fine before and after. 'dd

Hi, These patches add support for S4 to virtio (pci) and all drivers. For each driver, all vqs are removed before hibernation, and then re-created after restore. Some driver-specific uninit and init work is also done in the freeze and restore functions. All the drivers in testing work fine: * virtio-blk is used for the only disk in the VM, IO works fine before and after. 'dd

Hi, These patches add support for S4 to virtio (pci) and all drivers. Michael saw some race in virtio-net module removal which will need a similar fix for the freeze code as well. I'll update the virtio-net patch with that fix once the fix is settled upon and applied. For each driver, all vqs are removed before hibernation, and then re-created after restore. Some driver-specific uninit

Hi, These patches add support for S4 to virtio (pci) and all drivers. Michael saw some race in virtio-net module removal which will need a similar fix for the freeze code as well. I'll update the virtio-net patch with that fix once the fix is settled upon and applied. For each driver, all vqs are removed before hibernation, and then re-created after restore. Some driver-specific uninit

The previous version did not prevent updating the balloon when it was being removed. There was an idea to update the stats in a separate work and cancel it after the config reset. But this does not seem to work. The code for updating the stats communicates with the host. IMHO, it should not run after the reset (flushing buffers). Therefore I decided to use a boolean value and a spin lock (inspired

The previous version did not prevent updating the balloon when it was being removed. There was an idea to update the stats in a separate work and cancel it after the config reset. But this does not seem to work. The code for updating the stats communicates with the host. IMHO, it should not run after the reset (flushing buffers). Therefore I decided to use a boolean value and a spin lock (inspired

Peter Mladek reported that balloon might never refill completely after restore. This is because fill_balloon is only called once there. Calling fill_balloon repeatedly seems too aggressive, especially in light of the fact that it sleeps on failure: let's wake the config change handler and fill it asynchronously. Reported-by: Petr Mladek <pmladek at suse.com> Signed-off-by: Michael S.

Peter Mladek reported that balloon might never refill completely after restore. This is because fill_balloon is only called once there. Calling fill_balloon repeatedly seems too aggressive, especially in light of the fact that it sleeps on failure: let's wake the config change handler and fill it asynchronously. Reported-by: Petr Mladek <pmladek at suse.com> Signed-off-by: Michael S.

On Fri, Jul 10, 2020 at 09:13:41AM -0700, Alexander Duyck wrote: > On Fri, Jul 10, 2020 at 4:31 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > Page reporting features were never supported by legacy hypervisors. > > Supporting them poses a problem: should we use native endian-ness (like > > current code assumes)? Or little endian-ness like the virtio spec

On Fri, Jul 10, 2020 at 09:13:41AM -0700, Alexander Duyck wrote: > On Fri, Jul 10, 2020 at 4:31 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > Page reporting features were never supported by legacy hypervisors. > > Supporting them poses a problem: should we use native endian-ness (like > > current code assumes)? Or little endian-ness like the virtio spec

Page reporting features were never supported by legacy hypervisors. Supporting them poses a problem: should we use native endian-ness (like current code assumes)? Or little endian-ness like the virtio spec says? Rather than try to figure out, and since results of incorrect endian-ness are dire, let's just block this configuration. Cc: stable at vger.kernel.org Signed-off-by: Michael S.

Page reporting features were never supported by legacy hypervisors. Supporting them poses a problem: should we use native endian-ness (like current code assumes)? Or little endian-ness like the virtio spec says? Rather than try to figure out, and since results of incorrect endian-ness are dire, let's just block this configuration. Cc: stable at vger.kernel.org Signed-off-by: Michael S.