From: Gleb Natapov <gleb@redhat.com>
To: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Cc: Avi Kivity <avi@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
LKML <linux-kernel@vger.kernel.org>, KVM <kvm@vger.kernel.org>
Subject: Re: [RFC PATCH v2 7/7] KVM: KVM: don't break vcpu 'halt' state due to apfs
Date: Tue, 2 Nov 2010 09:45:45 +0200 [thread overview]
Message-ID: <20101102074545.GC7881@redhat.com> (raw)
In-Reply-To: <4CCFBE4E.3090804@cn.fujitsu.com>
On Tue, Nov 02, 2010 at 03:31:26PM +0800, Xiao Guangrong wrote:
> On 11/02/2010 02:56 PM, Gleb Natapov wrote:
> > On Tue, Nov 02, 2010 at 10:30:10AM +0800, Xiao Guangrong wrote:
> >> On 11/01/2010 08:55 PM, Gleb Natapov wrote:
> >>
> >>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> >>> index 2cfdf2d..f7aed95 100644
> >>> --- a/arch/x86/kvm/x86.c
> >>> +++ b/arch/x86/kvm/x86.c
> >>> @@ -5295,8 +5295,9 @@ static int __vcpu_run(struct kvm_vcpu *vcpu)
> >>> {
> >>> switch(vcpu->arch.mp_state) {
> >>> case KVM_MP_STATE_HALTED:
> >>> - vcpu->arch.mp_state =
> >>> - KVM_MP_STATE_RUNNABLE;
> >>> + if (list_empty_careful(&vcpu->async_pf.done))
> >>> + vcpu->arch.mp_state =
> >>> + KVM_MP_STATE_RUNNABLE;
> >>
> >> if nmi/interrupt and apfs completed event occur at the same time, we will miss to
> >> exit halt sate. Maybe we can check the pending event here, see below patch please.
> >>
> > No, we will not. If nmi/interrupt and apfs completed event occur at the same
> > time kvm_vcpu_block() will exit with KVM_REQ_UNHALT set, but cpu will
> > not be unhalted because of list_empty_careful(&vcpu->async_pf.done)
> > check. Vcpu then will process pending apf completion and enter
> > kvm_vcpu_block() again which will immediately exit because
> > kvm_arch_vcpu_runnable() will return true since there is pending
> > nmi/interrupt. This time vcpu will be unhalted.
>
> Thanks for your explanation, but if it has nmi/interrupt pending,
> kvm_arch_can_inject_async_page_present() always return false in PV guest case,
> it can not process pending apf completion, so, the vcpu is remain halt state
> forever?
>
kvm_event_needs_reinjection() checks for nmi/interrupts that
need reinjection (not injection). Those are nmi/interrupts that
was injected but injection failed for some reason. For nmi, for
instance, kvm_arch_vcpu_runnable() checks vcpu->arch.nmi_pending,
but kvm_event_needs_reinjection() checks for vcpu->arch.nmi_injected.
NMI moves from nmi_pending to nmi_injected when it is injected into vcpu
for the first time. CPU cannot be halted in this state.
> Also, the pv guest can only handle an apf completion at one time, it can not ensure
> vcpu->async_pf.done is empty after kvm_check_async_pf_completion()
>
In case of PV guest it will be woken up by apf completion by
kvm_arch_async_page_present() below.
> >
> >>> case KVM_MP_STATE_RUNNABLE:
> >>> vcpu->arch.apf.halted = false;
> >>> break;
> >>> @@ -6279,6 +6280,7 @@ void kvm_arch_async_page_present(struct kvm_vcpu *vcpu,
> >>> vcpu->arch.fault.error_code = 0;
> >>> vcpu->arch.fault.address = work->arch.token;
> >>> kvm_inject_page_fault(vcpu);
> >>> + vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE;
> >>> }
> >>> }
> >>
> >> Have a stupid question, why we make the vcpu runnable here? Sorry i don't know
> >> kvm pv guest to much. :-(
> > Because kvm_arch_vcpu_runnable() does not check for pending exceptions.
> > Since now we do not unhalt vcpu when apf completion happens we need to
> > unhalt it here. But, as I said, the patch is untested.
> >
>
> As i know, exception can not let guest exit halt state, only NMI/interruption can do it, yes? :-)
On physical HW exception cannot happen while cpu is in halt state, but
with PV we define what guest can and cannot expect, so when guest
explicitly enables apf it should be able to handle it during halt.
--
Gleb.
next prev parent reply other threads:[~2010-11-02 7:45 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-01 8:58 [PATCH v2 1/7] KVM: fix tracing kvm_try_async_get_page Xiao Guangrong
2010-11-01 8:59 ` [PATCH v2 2/7] KVM: cleanup aysnc_pf tracepoints Xiao Guangrong
2010-11-01 9:00 ` [PATCH v2 3/7] KVM: fix searching async gfn in kvm_async_pf_gfn_slot Xiao Guangrong
2010-11-01 9:01 ` [PATCH v2 4/7] KVM: avoid unnecessary wait for a async pf Xiao Guangrong
2010-11-01 9:25 ` Gleb Natapov
2010-11-01 9:02 ` [PATCH v2 5/7] KVM: handle more completed apfs if possible Xiao Guangrong
2010-11-01 9:24 ` Gleb Natapov
2010-11-01 9:34 ` Xiao Guangrong
2010-11-02 9:35 ` [PATCH v3 " Xiao Guangrong
2010-11-02 12:38 ` Gleb Natapov
2010-11-01 9:03 ` [RFC PATCH v2 6/7] KVM: fix the race while wakeup all pv guest Xiao Guangrong
2010-11-01 12:58 ` Gleb Natapov
2010-11-01 9:05 ` [RFC PATCH v2 7/7] KVM: KVM: don't break vcpu 'halt' state due to apfs Xiao Guangrong
2010-11-01 12:55 ` Gleb Natapov
2010-11-02 2:30 ` Xiao Guangrong
2010-11-02 6:56 ` Gleb Natapov
2010-11-02 7:31 ` Xiao Guangrong
2010-11-02 7:45 ` Gleb Natapov [this message]
2010-11-02 9:09 ` Xiao Guangrong
2010-11-02 9:14 ` Gleb Natapov
2010-11-02 9:30 ` Xiao Guangrong
2010-11-02 12:39 ` Gleb Natapov
2010-11-03 9:47 ` Xiao Guangrong
2010-11-03 9:45 ` Gleb Natapov
2010-11-03 13:43 ` Marcelo Tosatti
2010-11-01 13:09 ` [PATCH v2 1/7] KVM: fix tracing kvm_try_async_get_page Gleb Natapov
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=20101102074545.GC7881@redhat.com \
--to=gleb@redhat.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=xiaoguangrong@cn.fujitsu.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