public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Steffen Eiden <seiden@linux.ibm.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>, kvm@vger.kernel.org
Cc: borntraeger@de.ibm.com, frankja@linux.ibm.com, thuth@redhat.com,
	david@redhat.com, linux-s390@vger.kernel.org,
	linux-kernel@vger.kernel.org, scgl@linux.ibm.com,
	nrb@linux.ibm.com
Subject: Re: [PATCH v15 1/6] KVM: s390: pv: asynchronous destroy for reboot
Date: Wed, 12 Oct 2022 11:32:09 +0200	[thread overview]
Message-ID: <a29e8e63-3cbc-30cc-e0db-8e2bb8616ecb@linux.ibm.com> (raw)
In-Reply-To: <20221010145442.85867-2-imbrenda@linux.ibm.com>



On 10/10/22 16:54, Claudio Imbrenda wrote:
> Until now, destroying a protected guest was an entirely synchronous
> operation that could potentially take a very long time, depending on
> the size of the guest, due to the time needed to clean up the address
> space from protected pages.
> 
> This patch implements an asynchronous destroy mechanism, that allows a
> protected guest to reboot significantly faster than previously.
> 
> This is achieved by clearing the pages of the old guest in background.
> In case of reboot, the new guest will be able to run in the same
> address space almost immediately.
> 
> The old protected guest is then only destroyed when all of its memory
> has been destroyed or otherwise made non protected.
> 
> Two new PV commands are added for the KVM_S390_PV_COMMAND ioctl:
> 
> KVM_PV_ASYNC_CLEANUP_PREPARE: set aside the current protected VM for
> later asynchronous teardown. The current KVM VM will then continue
> immediately as non-protected. If a protected VM had already been
> set aside for asynchronous teardown, but without starting the teardown
> process, this call will fail. There can be at most one VM set aside at
> any time. Once it is set aside, the protected VM only exists in the
> context of the Ultravisor, it is not associated with the KVM VM
> anymore. Its protected CPUs have already been destroyed, but not its
> memory. This command can be issued again immediately after starting
> KVM_PV_ASYNC_CLEANUP_PERFORM, without having to wait for completion.
> 
> KVM_PV_ASYNC_CLEANUP_PERFORM: tears down the protected VM previously
> set aside using KVM_PV_ASYNC_CLEANUP_PREPARE. Ideally the
> KVM_PV_ASYNC_CLEANUP_PERFORM PV command should be issued by userspace
> from a separate thread. If a fatal signal is received (or if the
> process terminates naturally), the command will terminate immediately
> without completing. All protected VMs whose teardown was interrupted
> will be put in the need_cleanup list. The rest of the normal KVM
> teardown process will take care of properly cleaning up all remaining
> protected VMs, including the ones on the need_cleanup list.
> 
> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
> Reviewed-by: Nico Boehr <nrb@linux.ibm.com>
> Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>

[snip]

  reply	other threads:[~2022-10-12  9:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-10 14:54 [PATCH v15 0/6] KVM: s390: pv: implement lazy destroy for reboot Claudio Imbrenda
2022-10-10 14:54 ` [PATCH v15 1/6] KVM: s390: pv: asynchronous " Claudio Imbrenda
2022-10-12  9:32   ` Steffen Eiden [this message]
2022-10-10 14:54 ` [PATCH v15 2/6] KVM: s390: pv: api documentation for asynchronous destroy Claudio Imbrenda
2022-10-10 14:54 ` [PATCH v15 3/6] KVM: s390: pv: add KVM_CAP_S390_PROTECTED_ASYNC_DISABLE Claudio Imbrenda
2022-10-10 14:54 ` [PATCH v15 4/6] KVM: s390: pv: avoid export before import if possible Claudio Imbrenda
2022-10-10 14:54 ` [PATCH v15 5/6] KVM: s390: pv: support for Destroy fast UVC Claudio Imbrenda
2022-10-10 14:54 ` [PATCH v15 6/6] KVM: s390: pv: module parameter to fence asynchronous destroy Claudio Imbrenda
2022-10-12  8:51   ` Nico Boehr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a29e8e63-3cbc-30cc-e0db-8e2bb8616ecb@linux.ibm.com \
    --to=seiden@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=nrb@linux.ibm.com \
    --cc=scgl@linux.ibm.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox