From: Gleb Natapov <gleb@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Cornelia Huck <cornelia.huck@de.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
KVM <kvm@vger.kernel.org>,
linux-s390 <linux-s390@vger.kernel.org>,
Dominik Dingel <dingel@linux.vnet.ibm.com>
Subject: Re: [Patchv5 5/7] KVM: async_pf: Allow to wait for outstanding work
Date: Sun, 13 Oct 2013 12:08:41 +0300 [thread overview]
Message-ID: <20131013090840.GA7063@redhat.com> (raw)
In-Reply-To: <20131013084802.GC15657@redhat.com>
On Sun, Oct 13, 2013 at 11:48:03AM +0300, Gleb Natapov wrote:
> On Tue, Oct 08, 2013 at 04:54:58PM +0200, Christian Borntraeger wrote:
> > From: Dominik Dingel <dingel@linux.vnet.ibm.com>
> >
> > kvm_clear_async_pf_completion get an additional flag to either cancel outstanding
> > work or wait for oustanding work to be finished, x86 currentlx cancels all work.
> >
> I do not see why x86 would not cancel all work in the feature, so the
> flag seems to be always true on s390 and always false on x86, which
> means that it is better to make it compile time option, same as
> KVM_ASYNC_PF_SYNC. Actually we can reuse KVM_ASYNC_PF_SYNC in
> kvm_clear_async_pf_completion_queue() instead of adding another one.
>
Spoke to soon. I see that s390 uses both true and false, mostly false.
Lets add another function kvm_drain_async_pf_completion_queue() instead
of new parameter.
> > Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
> > Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> > ---
> > arch/x86/kvm/x86.c | 8 ++++----
> > include/linux/kvm_host.h | 2 +-
> > virt/kvm/async_pf.c | 6 +++++-
> > 3 files changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 187f824..00a4262 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -539,7 +539,7 @@ int kvm_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0)
> > kvm_x86_ops->set_cr0(vcpu, cr0);
> >
> > if ((cr0 ^ old_cr0) & X86_CR0_PG) {
> > - kvm_clear_async_pf_completion_queue(vcpu);
> > + kvm_clear_async_pf_completion_queue(vcpu, false);
> > kvm_async_pf_hash_reset(vcpu);
> > }
> >
> > @@ -1911,7 +1911,7 @@ static int kvm_pv_enable_async_pf(struct kvm_vcpu *vcpu, u64 data)
> > vcpu->arch.apf.msr_val = data;
> >
> > if (!(data & KVM_ASYNC_PF_ENABLED)) {
> > - kvm_clear_async_pf_completion_queue(vcpu);
> > + kvm_clear_async_pf_completion_queue(vcpu, false);
> > kvm_async_pf_hash_reset(vcpu);
> > return 0;
> > }
> > @@ -6742,7 +6742,7 @@ void kvm_vcpu_reset(struct kvm_vcpu *vcpu)
> >
> > kvmclock_reset(vcpu);
> >
> > - kvm_clear_async_pf_completion_queue(vcpu);
> > + kvm_clear_async_pf_completion_queue(vcpu, false);
> > kvm_async_pf_hash_reset(vcpu);
> > vcpu->arch.apf.halted = false;
> >
> > @@ -7015,7 +7015,7 @@ static void kvm_free_vcpus(struct kvm *kvm)
> > * Unpin any mmu pages first.
> > */
> > kvm_for_each_vcpu(i, vcpu, kvm) {
> > - kvm_clear_async_pf_completion_queue(vcpu);
> > + kvm_clear_async_pf_completion_queue(vcpu, false);
> > kvm_unload_vcpu_mmu(vcpu);
> > }
> > kvm_for_each_vcpu(i, vcpu, kvm)
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > index b4e8666..223fcf3 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -192,7 +192,7 @@ struct kvm_async_pf {
> > struct page *page;
> > };
> >
> > -void kvm_clear_async_pf_completion_queue(struct kvm_vcpu *vcpu);
> > +void kvm_clear_async_pf_completion_queue(struct kvm_vcpu *vcpu, bool flush);
> > void kvm_check_async_pf_completion(struct kvm_vcpu *vcpu);
> > int kvm_setup_async_pf(struct kvm_vcpu *vcpu, gva_t gva, unsigned long hva,
> > struct kvm_arch_async_pf *arch);
> > diff --git a/virt/kvm/async_pf.c b/virt/kvm/async_pf.c
> > index 8f57d63..3e13a73 100644
> > --- a/virt/kvm/async_pf.c
> > +++ b/virt/kvm/async_pf.c
> > @@ -107,7 +107,7 @@ static void async_pf_execute(struct work_struct *work)
> > kvm_put_kvm(vcpu->kvm);
> > }
> >
> > -void kvm_clear_async_pf_completion_queue(struct kvm_vcpu *vcpu)
> > +void kvm_clear_async_pf_completion_queue(struct kvm_vcpu *vcpu, bool flush)
> > {
> > /* cancel outstanding work queue item */
> > while (!list_empty(&vcpu->async_pf.queue)) {
> > @@ -115,6 +115,10 @@ void kvm_clear_async_pf_completion_queue(struct kvm_vcpu *vcpu)
> > list_entry(vcpu->async_pf.queue.next,
> > typeof(*work), queue);
> > list_del(&work->queue);
> > + if (flush) {
> > + flush_work(&work->work);
> > + continue;
> > + }
> > if (cancel_work_sync(&work->work)) {
> > mmdrop(work->mm);
> > kvm_put_kvm(vcpu->kvm); /* == work->vcpu->kvm */
> > --
> > 1.8.3.1
>
> --
> Gleb.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gleb.
next prev parent reply other threads:[~2013-10-13 9:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-08 14:54 [PATCHv5 0/7] aync page fault support for s390 (plus flic) Christian Borntraeger
2013-10-08 14:54 ` [Patchv5 1/7] KVM: s390: add and extend interrupt information data structs Christian Borntraeger
2013-10-08 14:54 ` [Patchv5 2/7] KVM: s390: add floating irq controller Christian Borntraeger
2013-10-13 8:39 ` Gleb Natapov
2013-10-14 7:58 ` Christian Borntraeger
2013-10-14 10:21 ` Gleb Natapov
2013-10-14 8:28 ` Jens Freimann
2013-10-14 9:07 ` Gleb Natapov
2013-10-14 11:13 ` Jens Freimann
2013-10-14 11:31 ` Gleb Natapov
2013-10-14 13:35 ` Gleb Natapov
2013-10-08 14:54 ` [Patchv5 3/7] KVM: s390: Add FAULT_FLAG_RETRY_NOWAIT for guest fault Christian Borntraeger
2013-10-08 14:54 ` [Patchv5 4/7] KVM: async_pf: Provide additional direct page notification Christian Borntraeger
2013-10-08 14:54 ` [Patchv5 5/7] KVM: async_pf: Allow to wait for outstanding work Christian Borntraeger
2013-10-13 8:48 ` Gleb Natapov
2013-10-13 9:08 ` Gleb Natapov [this message]
2013-10-08 14:54 ` [Patchv5 6/7] KVM: async_pf: Async page fault support on s390 Christian Borntraeger
2013-10-13 9:15 ` Gleb Natapov
2013-10-13 9:30 ` Gleb Natapov
2013-10-08 14:55 ` [Patchv5 7/7] KVM: async_pf: Exploit one reg interface for pfault Christian Borntraeger
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=20131013090840.GA7063@redhat.com \
--to=gleb@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cornelia.huck@de.ibm.com \
--cc=dingel@linux.vnet.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=schwidefsky@de.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.