All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>,
	kvm list <kvm@vger.kernel.org>, Avi Kivity <avi@redhat.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [PATCH] kvm: notify host when guest paniced
Date: Tue, 28 Feb 2012 12:45:28 +0200	[thread overview]
Message-ID: <20120228104528.GB24600@redhat.com> (raw)
In-Reply-To: <4F4CAA43.3020805@siemens.com>

On Tue, Feb 28, 2012 at 11:19:47AM +0100, Jan Kiszka wrote:
> On 2012-02-28 10:42, Wen Congyang wrote:
> > At 02/28/2012 05:34 PM, Jan Kiszka Wrote:
> >> On 2012-02-28 09:23, Wen Congyang wrote:
> >>> At 02/27/2012 11:08 PM, Jan Kiszka Wrote:
> >>>> On 2012-02-27 04:01, Wen Congyang wrote:
> >>>>> We can know the guest is paniced when the guest runs on xen.
> >>>>> But we do not have such feature on kvm. This patch implemnts
> >>>>> this feature, and the implementation is the same as xen:
> >>>>> register panic notifier, and call hypercall when the guest
> >>>>> is paniced.
> >>>>>
> >>>>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> >>>>> ---
> >>>>>  arch/x86/kernel/kvm.c    |   12 ++++++++++++
> >>>>>  arch/x86/kvm/svm.c       |    8 ++++++--
> >>>>>  arch/x86/kvm/vmx.c       |    8 ++++++--
> >>>>>  arch/x86/kvm/x86.c       |   13 +++++++++++--
> >>>>>  include/linux/kvm.h      |    1 +
> >>>>>  include/linux/kvm_para.h |    1 +
> >>>>>  6 files changed, 37 insertions(+), 6 deletions(-)
> >>>>>
> >>>>> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> >>>>> index f0c6fd6..b928d1d 100644
> >>>>> --- a/arch/x86/kernel/kvm.c
> >>>>> +++ b/arch/x86/kernel/kvm.c
> >>>>> @@ -331,6 +331,17 @@ static struct notifier_block kvm_pv_reboot_nb = {
> >>>>>  	.notifier_call = kvm_pv_reboot_notify,
> >>>>>  };
> >>>>>  
> >>>>> +static int
> >>>>> +kvm_pv_panic_notify(struct notifier_block *nb, unsigned long code, void *unused)
> >>>>> +{
> >>>>> +	kvm_hypercall0(KVM_HC_GUEST_PANIC);
> >>>>> +	return NOTIFY_DONE;
> >>>>> +}
> >>>>> +
> >>>>> +static struct notifier_block kvm_pv_panic_nb = {
> >>>>> +	.notifier_call = kvm_pv_panic_notify,
> >>>>> +};
> >>>>> +
> >>>>
> >>>> You should split up host and guest-side changes.
> >>>>
> >>>>>  static u64 kvm_steal_clock(int cpu)
> >>>>>  {
> >>>>>  	u64 steal;
> >>>>> @@ -417,6 +428,7 @@ void __init kvm_guest_init(void)
> >>>>>  
> >>>>>  	paravirt_ops_setup();
> >>>>>  	register_reboot_notifier(&kvm_pv_reboot_nb);
> >>>>> +	atomic_notifier_chain_register(&panic_notifier_list, &kvm_pv_panic_nb);
> >>>>>  	for (i = 0; i < KVM_TASK_SLEEP_HASHSIZE; i++)
> >>>>>  		spin_lock_init(&async_pf_sleepers[i].lock);
> >>>>>  	if (kvm_para_has_feature(KVM_FEATURE_ASYNC_PF))
> >>>>> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> >>>>> index 0b7690e..38b4705 100644
> >>>>> --- a/arch/x86/kvm/svm.c
> >>>>> +++ b/arch/x86/kvm/svm.c
> >>>>> @@ -1900,10 +1900,14 @@ static int halt_interception(struct vcpu_svm *svm)
> >>>>>  
> >>>>>  static int vmmcall_interception(struct vcpu_svm *svm)
> >>>>>  {
> >>>>> +	int ret;
> >>>>> +
> >>>>>  	svm->next_rip = kvm_rip_read(&svm->vcpu) + 3;
> >>>>>  	skip_emulated_instruction(&svm->vcpu);
> >>>>> -	kvm_emulate_hypercall(&svm->vcpu);
> >>>>> -	return 1;
> >>>>> +	ret = kvm_emulate_hypercall(&svm->vcpu);
> >>>>> +
> >>>>> +	/* Ignore the error? */
> >>>>> +	return ret == 0 ? 0 : 1;
> >>>>
> >>>> Why can't kvm_emulate_hypercall return the right value?
> >>>
> >>> kvm_emulate_hypercall() will call kvm_hv_hypercall(), and
> >>> kvm_hv_hypercall() will return 0 when vcpu's CPL > 0.
> >>> If vcpu's CPL > 0, does kvm need to exit and tell it to
> >>> qemu?
> >>
> >> No, there is currently no exit to userspace due to hypercalls, neither
> >> of HV nor KVM kind.
> >>
> >> The point is that the return code of kvm_emulate_hypercall is unused so
> >> far, so you can easily redefine it to encode continue vs. exit to
> >> userspace. Once someone has different needs, this could still be
> >> refactored again.
> > 
> > So, it is OK to change the return value of kvm_hv_hypercall() if vcpu's
> > CPL > 0?
> 
> Yes, change it to encode what vendor modules need to return to their
> callers.
> 
Better introduce new request flag and set it in your hypercall emulation. See
how triple fault is handled.

--
			Gleb.

WARNING: multiple messages have this Message-ID (diff)
From: Gleb Natapov <gleb@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: kvm list <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	qemu-devel <qemu-devel@nongnu.org>, Avi Kivity <avi@redhat.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [Qemu-devel] [PATCH] kvm: notify host when guest paniced
Date: Tue, 28 Feb 2012 12:45:28 +0200	[thread overview]
Message-ID: <20120228104528.GB24600@redhat.com> (raw)
In-Reply-To: <4F4CAA43.3020805@siemens.com>

On Tue, Feb 28, 2012 at 11:19:47AM +0100, Jan Kiszka wrote:
> On 2012-02-28 10:42, Wen Congyang wrote:
> > At 02/28/2012 05:34 PM, Jan Kiszka Wrote:
> >> On 2012-02-28 09:23, Wen Congyang wrote:
> >>> At 02/27/2012 11:08 PM, Jan Kiszka Wrote:
> >>>> On 2012-02-27 04:01, Wen Congyang wrote:
> >>>>> We can know the guest is paniced when the guest runs on xen.
> >>>>> But we do not have such feature on kvm. This patch implemnts
> >>>>> this feature, and the implementation is the same as xen:
> >>>>> register panic notifier, and call hypercall when the guest
> >>>>> is paniced.
> >>>>>
> >>>>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> >>>>> ---
> >>>>>  arch/x86/kernel/kvm.c    |   12 ++++++++++++
> >>>>>  arch/x86/kvm/svm.c       |    8 ++++++--
> >>>>>  arch/x86/kvm/vmx.c       |    8 ++++++--
> >>>>>  arch/x86/kvm/x86.c       |   13 +++++++++++--
> >>>>>  include/linux/kvm.h      |    1 +
> >>>>>  include/linux/kvm_para.h |    1 +
> >>>>>  6 files changed, 37 insertions(+), 6 deletions(-)
> >>>>>
> >>>>> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> >>>>> index f0c6fd6..b928d1d 100644
> >>>>> --- a/arch/x86/kernel/kvm.c
> >>>>> +++ b/arch/x86/kernel/kvm.c
> >>>>> @@ -331,6 +331,17 @@ static struct notifier_block kvm_pv_reboot_nb = {
> >>>>>  	.notifier_call = kvm_pv_reboot_notify,
> >>>>>  };
> >>>>>  
> >>>>> +static int
> >>>>> +kvm_pv_panic_notify(struct notifier_block *nb, unsigned long code, void *unused)
> >>>>> +{
> >>>>> +	kvm_hypercall0(KVM_HC_GUEST_PANIC);
> >>>>> +	return NOTIFY_DONE;
> >>>>> +}
> >>>>> +
> >>>>> +static struct notifier_block kvm_pv_panic_nb = {
> >>>>> +	.notifier_call = kvm_pv_panic_notify,
> >>>>> +};
> >>>>> +
> >>>>
> >>>> You should split up host and guest-side changes.
> >>>>
> >>>>>  static u64 kvm_steal_clock(int cpu)
> >>>>>  {
> >>>>>  	u64 steal;
> >>>>> @@ -417,6 +428,7 @@ void __init kvm_guest_init(void)
> >>>>>  
> >>>>>  	paravirt_ops_setup();
> >>>>>  	register_reboot_notifier(&kvm_pv_reboot_nb);
> >>>>> +	atomic_notifier_chain_register(&panic_notifier_list, &kvm_pv_panic_nb);
> >>>>>  	for (i = 0; i < KVM_TASK_SLEEP_HASHSIZE; i++)
> >>>>>  		spin_lock_init(&async_pf_sleepers[i].lock);
> >>>>>  	if (kvm_para_has_feature(KVM_FEATURE_ASYNC_PF))
> >>>>> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> >>>>> index 0b7690e..38b4705 100644
> >>>>> --- a/arch/x86/kvm/svm.c
> >>>>> +++ b/arch/x86/kvm/svm.c
> >>>>> @@ -1900,10 +1900,14 @@ static int halt_interception(struct vcpu_svm *svm)
> >>>>>  
> >>>>>  static int vmmcall_interception(struct vcpu_svm *svm)
> >>>>>  {
> >>>>> +	int ret;
> >>>>> +
> >>>>>  	svm->next_rip = kvm_rip_read(&svm->vcpu) + 3;
> >>>>>  	skip_emulated_instruction(&svm->vcpu);
> >>>>> -	kvm_emulate_hypercall(&svm->vcpu);
> >>>>> -	return 1;
> >>>>> +	ret = kvm_emulate_hypercall(&svm->vcpu);
> >>>>> +
> >>>>> +	/* Ignore the error? */
> >>>>> +	return ret == 0 ? 0 : 1;
> >>>>
> >>>> Why can't kvm_emulate_hypercall return the right value?
> >>>
> >>> kvm_emulate_hypercall() will call kvm_hv_hypercall(), and
> >>> kvm_hv_hypercall() will return 0 when vcpu's CPL > 0.
> >>> If vcpu's CPL > 0, does kvm need to exit and tell it to
> >>> qemu?
> >>
> >> No, there is currently no exit to userspace due to hypercalls, neither
> >> of HV nor KVM kind.
> >>
> >> The point is that the return code of kvm_emulate_hypercall is unused so
> >> far, so you can easily redefine it to encode continue vs. exit to
> >> userspace. Once someone has different needs, this could still be
> >> refactored again.
> > 
> > So, it is OK to change the return value of kvm_hv_hypercall() if vcpu's
> > CPL > 0?
> 
> Yes, change it to encode what vendor modules need to return to their
> callers.
> 
Better introduce new request flag and set it in your hypercall emulation. See
how triple fault is handled.

--
			Gleb.

  reply	other threads:[~2012-02-28 10:45 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-27  3:01 [PATCH] kvm: notify host when guest paniced Wen Congyang
2012-02-27  3:01 ` [Qemu-devel] " Wen Congyang
2012-02-27  3:05 ` [PATCH]qemu: deal with guest paniced event Wen Congyang
2012-02-27  3:05   ` [Qemu-devel] " Wen Congyang
2012-02-27  8:59   ` Jan Kiszka
2012-02-27  8:59     ` [Qemu-devel] " Jan Kiszka
2012-02-27  8:59     ` Jan Kiszka
2012-03-01 16:51   ` [Qemu-devel] " Luiz Capitulino
2012-03-01 16:51     ` Luiz Capitulino
2012-03-02  0:40     ` Wen Congyang
2012-03-02  0:40       ` Wen Congyang
2012-02-27 15:08 ` [PATCH] kvm: notify host when guest paniced Jan Kiszka
2012-02-27 15:08   ` [Qemu-devel] " Jan Kiszka
2012-02-28  5:26   ` Wen Congyang
2012-02-28  5:26     ` [Qemu-devel] " Wen Congyang
2012-02-28  5:26     ` Wen Congyang
2012-02-28  8:07     ` Wen Congyang
2012-02-28  8:07       ` [Qemu-devel] " Wen Congyang
2012-02-28  8:23   ` Wen Congyang
2012-02-28  8:23     ` [Qemu-devel] " Wen Congyang
2012-02-28  9:34     ` Jan Kiszka
2012-02-28  9:34       ` [Qemu-devel] " Jan Kiszka
2012-02-28  9:34       ` Jan Kiszka
2012-02-28  9:42       ` Wen Congyang
2012-02-28  9:42         ` [Qemu-devel] " Wen Congyang
2012-02-28 10:19         ` Jan Kiszka
2012-02-28 10:19           ` [Qemu-devel] " Jan Kiszka
2012-02-28 10:45           ` Gleb Natapov [this message]
2012-02-28 10:45             ` Gleb Natapov
2012-02-29  1:08             ` Wen Congyang
2012-02-29  1:08               ` [Qemu-devel] " Wen Congyang
2012-02-29  9:36               ` Gleb Natapov
2012-02-29  9:36                 ` [Qemu-devel] " Gleb Natapov
2012-02-29 10:06                 ` Wen Congyang
2012-02-29 10:06                   ` [Qemu-devel] " Wen Congyang
2012-02-28 11:23 ` Avi Kivity
2012-02-28 11:23   ` [Qemu-devel] " Avi Kivity
2012-02-29  1:29   ` Wen Congyang
2012-02-29  1:29     ` [Qemu-devel] " Wen Congyang
2012-02-29  1:29     ` Wen Congyang
2012-02-29  9:49     ` Avi Kivity
2012-02-29  9:49       ` [Qemu-devel] " Avi Kivity
2012-02-29  9:55       ` Gleb Natapov
2012-02-29  9:55         ` [Qemu-devel] " Gleb Natapov
2012-02-29 10:00         ` Avi Kivity
2012-02-29 10:00           ` [Qemu-devel] " Avi Kivity
2012-02-29 10:00           ` Avi Kivity
2012-02-29 10:05           ` Gleb Natapov
2012-02-29 10:05             ` [Qemu-devel] " Gleb Natapov
2012-02-29 10:08             ` Avi Kivity
2012-02-29 10:08               ` [Qemu-devel] " Avi Kivity
2012-02-29 10:17               ` Wen Congyang
2012-02-29 10:17                 ` [Qemu-devel] " Wen Congyang
2012-02-29 10:39                 ` Avi Kivity
2012-02-29 10:39                   ` [Qemu-devel] " Avi Kivity
2012-03-01  3:34                   ` Wen Congyang
2012-03-01  3:34                     ` [Qemu-devel] " Wen Congyang
2012-03-01  3:34                     ` Wen Congyang
2012-03-01  5:21                   ` Wen Congyang
2012-03-01  5:21                     ` [Qemu-devel] " Wen Congyang
2012-02-29 10:44               ` Gleb Natapov
2012-02-29 10:44                 ` [Qemu-devel] " Gleb Natapov
2012-02-29 10:48                 ` Avi Kivity
2012-02-29 10:48                   ` [Qemu-devel] " Avi Kivity
2012-02-29 10:52                   ` Gleb Natapov
2012-02-29 10:52                     ` [Qemu-devel] " Gleb Natapov
2012-02-29  9:58       ` Daniel P. Berrange
2012-02-29  9:58         ` [Qemu-devel] " Daniel P. Berrange
2012-02-29 10:05         ` Avi Kivity
2012-02-29 10:05           ` [Qemu-devel] " Avi Kivity
2012-02-29 10:19           ` Daniel P. Berrange
2012-02-29 10:19             ` [Qemu-devel] " Daniel P. Berrange
2012-02-29 10:44             ` Avi Kivity
2012-02-29 10:44               ` [Qemu-devel] " Avi Kivity
2012-02-29 10:31           ` Wen Congyang
2012-02-29 10:31             ` [Qemu-devel] " Wen Congyang
2012-02-29 10:31             ` Wen Congyang
2012-02-29 10:46             ` Avi Kivity
2012-02-29 10:46               ` [Qemu-devel] " Avi Kivity
2012-02-29 10:46               ` Avi Kivity

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=20120228104528.GB24600@redhat.com \
    --to=gleb@redhat.com \
    --cc=avi@redhat.com \
    --cc=berrange@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=wency@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 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.