From: Wen Congyang <wency@cn.fujitsu.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.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: Wed, 29 Feb 2012 18:06:40 +0800 [thread overview]
Message-ID: <4F4DF8B0.9000608@cn.fujitsu.com> (raw)
In-Reply-To: <20120229093627.GC24600@redhat.com>
At 02/29/2012 05:36 PM, Gleb Natapov Wrote:
> On Wed, Feb 29, 2012 at 09:08:52AM +0800, Wen Congyang wrote:
>> At 02/28/2012 06:45 PM, Gleb Natapov Wrote:
>>> 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.
>>
>> triple fault sets KVM_EXIT_SHUTDOWN and exits to userspace. Do you mean introduce
>> a new value(like KVM_EXIT_SHUTDOWN)?
>>
> I mean introduce new request bit (like KVM_REQ_TRIPLE_FAULT) and set it
> in your hypercall if exit to userspace is needed instead of changing
> return values.
I donot notice it. Thanks for you suggestion. I will modify my patch.
Thanks
Wen Congyang
>
> --
> Gleb.
>
WARNING: multiple messages have this Message-ID (diff)
From: Wen Congyang <wency@cn.fujitsu.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: kvm list <kvm@vger.kernel.org>,
Jan Kiszka <jan.kiszka@siemens.com>,
"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: Wed, 29 Feb 2012 18:06:40 +0800 [thread overview]
Message-ID: <4F4DF8B0.9000608@cn.fujitsu.com> (raw)
In-Reply-To: <20120229093627.GC24600@redhat.com>
At 02/29/2012 05:36 PM, Gleb Natapov Wrote:
> On Wed, Feb 29, 2012 at 09:08:52AM +0800, Wen Congyang wrote:
>> At 02/28/2012 06:45 PM, Gleb Natapov Wrote:
>>> 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.
>>
>> triple fault sets KVM_EXIT_SHUTDOWN and exits to userspace. Do you mean introduce
>> a new value(like KVM_EXIT_SHUTDOWN)?
>>
> I mean introduce new request bit (like KVM_REQ_TRIPLE_FAULT) and set it
> in your hypercall if exit to userspace is needed instead of changing
> return values.
I donot notice it. Thanks for you suggestion. I will modify my patch.
Thanks
Wen Congyang
>
> --
> Gleb.
>
next prev parent reply other threads:[~2012-02-29 10:06 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
2012-02-28 10:45 ` [Qemu-devel] " 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 [this message]
2012-02-29 10:06 ` 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=4F4DF8B0.9000608@cn.fujitsu.com \
--to=wency@cn.fujitsu.com \
--cc=avi@redhat.com \
--cc=berrange@redhat.com \
--cc=gleb@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 \
/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.