From: Wen Congyang <wency@cn.fujitsu.com>
To: Avi Kivity <avi@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>, 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>,
Amit Shah <amit.shah@redhat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
Date: Wed, 14 Mar 2012 19:11:32 +0800 [thread overview]
Message-ID: <4F607CE4.2060809@cn.fujitsu.com> (raw)
In-Reply-To: <4F607789.4010109@redhat.com>
At 03/14/2012 06:48 PM, Avi Kivity Wrote:
> On 03/14/2012 12:46 PM, Gleb Natapov wrote:
>> On Wed, Mar 14, 2012 at 12:29:57PM +0200, Avi Kivity wrote:
>>> On 03/14/2012 12:26 PM, Wen Congyang wrote:
>>>>>> If so, is this channel visible to guest userspace? If the channle is visible to guest
>>>>>> userspace, the program running in userspace may write the same message to the channel.
>>>>>>
>>>>>
>>>>> Surely there's some kind of access control on channels.
>>>>
>>>> The virtio-serial depends on more things than touching the hypervisor. So I think touching
>>>> the hypervisor is more reliable than using virtio-serial device, and it is very simple and
>>>> easy to use.
>>>>
>>>> If we pass something from guest userspace to host, we can use virtio-serial. But If we pass
>>>> something from guest kernelspace to host, I still prefer to touch the hypervisor.
>>>
>>> There's no argument that it's easier. My concern is different, we're
>>> adding more and more stuff to the hypervisor because it's easier, which
>>> bloats it. Every time we do it we add to compatibility and security
>>> problems.
>>>
>>> The panic notification is *really* simple, so I don't expect it to cause
>>> a lot of problems. But still, if it's possible not to change the
>>> hypervisor, we must make an effort in that direction.
>>>
>> One more point against using virtio-serial is that it will be likely
>> compiled as a module which means panic during early boot will not be
>> reported.
>
> I don't think we want to use the driver. Instead, have a small piece of
> code that resets the device and pushes out a string (the panic message?)
> without any interrupts etc.
>
> It's still going to be less reliable than a hypercall, I agree.
Do you still want to use complicated and less reliable way?
I think the other ones prefer to touch the hypervisor.
Thanks
Wen Congyang
WARNING: multiple messages have this Message-ID (diff)
From: Wen Congyang <wency@cn.fujitsu.com>
To: Avi Kivity <avi@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>,
"Daniel P. Berrange" <berrange@redhat.com>,
kvm list <kvm@vger.kernel.org>,
qemu-devel <qemu-devel@nongnu.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Jan Kiszka <jan.kiszka@siemens.com>,
Amit Shah <amit.shah@redhat.com>
Subject: Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
Date: Wed, 14 Mar 2012 19:11:32 +0800 [thread overview]
Message-ID: <4F607CE4.2060809@cn.fujitsu.com> (raw)
In-Reply-To: <4F607789.4010109@redhat.com>
At 03/14/2012 06:48 PM, Avi Kivity Wrote:
> On 03/14/2012 12:46 PM, Gleb Natapov wrote:
>> On Wed, Mar 14, 2012 at 12:29:57PM +0200, Avi Kivity wrote:
>>> On 03/14/2012 12:26 PM, Wen Congyang wrote:
>>>>>> If so, is this channel visible to guest userspace? If the channle is visible to guest
>>>>>> userspace, the program running in userspace may write the same message to the channel.
>>>>>>
>>>>>
>>>>> Surely there's some kind of access control on channels.
>>>>
>>>> The virtio-serial depends on more things than touching the hypervisor. So I think touching
>>>> the hypervisor is more reliable than using virtio-serial device, and it is very simple and
>>>> easy to use.
>>>>
>>>> If we pass something from guest userspace to host, we can use virtio-serial. But If we pass
>>>> something from guest kernelspace to host, I still prefer to touch the hypervisor.
>>>
>>> There's no argument that it's easier. My concern is different, we're
>>> adding more and more stuff to the hypervisor because it's easier, which
>>> bloats it. Every time we do it we add to compatibility and security
>>> problems.
>>>
>>> The panic notification is *really* simple, so I don't expect it to cause
>>> a lot of problems. But still, if it's possible not to change the
>>> hypervisor, we must make an effort in that direction.
>>>
>> One more point against using virtio-serial is that it will be likely
>> compiled as a module which means panic during early boot will not be
>> reported.
>
> I don't think we want to use the driver. Instead, have a small piece of
> code that resets the device and pushes out a string (the panic message?)
> without any interrupts etc.
>
> It's still going to be less reliable than a hypercall, I agree.
Do you still want to use complicated and less reliable way?
I think the other ones prefer to touch the hypervisor.
Thanks
Wen Congyang
next prev parent reply other threads:[~2012-03-14 11:11 UTC|newest]
Thread overview: 114+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-08 7:57 [PATCH 0/2 v3] kvm: notify host when guest panicked Wen Congyang
2012-03-08 8:02 ` [PATCH 1/2 " Wen Congyang
2012-03-08 8:04 ` [PATCH 2/2 v3] kvm: set exit_reason to KVM_EXIT_GUEST_PANICKED " Wen Congyang
2012-03-08 8:06 ` [PATCH 1/2 v3] update linux-headers Wen Congyang
2012-03-08 8:07 ` [PATCH 2/2 v3] deal with guest panicked event Wen Congyang
2012-03-08 10:08 ` Jan Kiszka
2012-03-08 10:11 ` Wen Congyang
2012-03-08 10:15 ` [RESEND][PATCH " Wen Congyang
2012-03-08 11:28 ` Avi Kivity
2012-03-08 11:36 ` Daniel P. Berrange
2012-03-08 11:52 ` Avi Kivity
2012-03-08 11:56 ` Daniel P. Berrange
2012-03-08 11:56 ` Daniel P. Berrange
2012-03-09 22:22 ` Marcelo Tosatti
2012-03-21 19:01 ` [Qemu-devel] " Anthony Liguori
2012-03-12 1:46 ` Wen Congyang
2012-03-12 1:46 ` Wen Congyang
2012-03-08 11:13 ` [PATCH 0/2 v3] kvm: notify host when guest panicked Avi Kivity
2012-03-08 11:13 ` Avi Kivity
2012-03-09 1:21 ` Wen Congyang
2012-03-09 1:21 ` Wen Congyang
2012-03-12 9:04 ` Wen Congyang
2012-03-12 10:33 ` Avi Kivity
2012-03-13 6:44 ` Wen Congyang
2012-03-13 8:54 ` Avi Kivity
2012-03-13 9:18 ` Daniel P. Berrange
2012-03-13 10:47 ` Avi Kivity
2012-03-13 10:47 ` Avi Kivity
2012-03-14 8:29 ` Wen Congyang
2012-03-14 8:29 ` Wen Congyang
2012-03-14 9:24 ` Avi Kivity
2012-03-14 9:53 ` Wen Congyang
2012-03-14 10:07 ` Avi Kivity
2012-03-14 10:26 ` Wen Congyang
2012-03-14 10:29 ` Avi Kivity
2012-03-14 10:46 ` Gleb Natapov
2012-03-14 10:48 ` Avi Kivity
2012-03-14 11:11 ` Wen Congyang [this message]
2012-03-14 11:11 ` Wen Congyang
2012-03-14 13:07 ` Avi Kivity
2012-03-14 13:13 ` Avi Kivity
2012-03-14 13:14 ` Gleb Natapov
2012-03-14 13:16 ` Avi Kivity
2012-03-14 13:25 ` Gleb Natapov
2012-03-14 18:46 ` Eric Northup
2012-03-15 7:01 ` Wen Congyang
2012-03-15 7:01 ` Wen Congyang
2012-03-15 10:39 ` Gleb Natapov
2012-03-15 11:25 ` Jan Kiszka
2012-03-15 11:46 ` Avi Kivity
2012-03-16 8:05 ` Wen Congyang
2012-03-21 19:12 ` [Qemu-devel] " Anthony Liguori
2012-03-22 8:34 ` Wen Congyang
2012-03-14 18:47 ` Eric Northup
2012-03-14 18:47 ` Eric Northup
2012-03-14 10:37 ` Amit Shah
2012-03-14 10:37 ` Amit Shah
2012-03-14 10:52 ` Wen Congyang
2012-03-14 10:52 ` Gleb Natapov
2012-03-14 10:57 ` Wen Congyang
2012-03-14 10:58 ` Gleb Natapov
2012-03-14 11:13 ` Wen Congyang
2012-03-14 11:13 ` Wen Congyang
2012-03-14 10:52 ` Avi Kivity
2012-03-14 10:58 ` Wen Congyang
2012-03-14 10:59 ` Daniel P. Berrange
2012-03-14 11:06 ` Wen Congyang
2012-03-14 11:11 ` Gleb Natapov
2012-03-14 11:17 ` Daniel P. Berrange
2012-03-14 10:59 ` Gleb Natapov
2012-03-14 10:57 ` Amit Shah
2012-03-14 9:51 ` Amit Shah
2012-03-14 10:04 ` Wen Congyang
2012-03-14 10:08 ` Avi Kivity
2012-03-14 10:08 ` Avi Kivity
2012-03-14 10:40 ` Amit Shah
2012-03-14 10:42 ` Gleb Natapov
2012-03-14 10:57 ` Daniel P. Berrange
2012-03-14 10:57 ` Daniel P. Berrange
2012-03-14 11:01 ` Wen Congyang
2012-03-14 11:01 ` Wen Congyang
2012-03-21 19:04 ` [Qemu-devel] " Anthony Liguori
2012-03-22 7:33 ` Gleb Natapov
2012-03-12 10:31 ` Avi Kivity
2012-03-19 7:33 ` Wen Congyang
2012-03-20 9:59 ` Wen Congyang
2012-03-20 15:45 ` Gleb Natapov
2012-03-21 0:56 ` Wen Congyang
2012-03-21 9:11 ` Gleb Natapov
2012-03-21 9:35 ` Wen Congyang
2012-03-21 9:35 ` Wen Congyang
2012-03-21 9:42 ` Gleb Natapov
2012-03-21 16:18 ` Corey Minyard
2012-03-21 16:24 ` Gleb Natapov
2012-03-21 16:24 ` Gleb Natapov
2012-03-21 16:25 ` Avi Kivity
2012-03-21 17:04 ` Daniel P. Berrange
2012-03-21 17:34 ` Avi Kivity
2012-03-21 18:17 ` Jan Kiszka
2012-03-21 18:17 ` Jan Kiszka
2012-03-21 19:19 ` [Qemu-devel] " Anthony Liguori
2012-03-22 1:05 ` Wen Congyang
2012-03-22 1:05 ` [Qemu-devel] " Wen Congyang
2012-03-22 7:31 ` Gleb Natapov
2012-03-22 7:44 ` Wen Congyang
2012-03-22 8:36 ` Gleb Natapov
2012-03-22 8:36 ` [Qemu-devel] " Gleb Natapov
2012-03-22 7:28 ` Gleb Natapov
2012-03-22 7:28 ` [Qemu-devel] " Gleb Natapov
2012-03-22 7:40 ` Wen Congyang
2012-04-17 3:14 ` Wen Congyang
2012-04-02 10:05 ` Wen Congyang
2012-04-02 10:54 ` Amit Shah
2012-04-02 10:54 ` Amit Shah
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=4F607CE4.2060809@cn.fujitsu.com \
--to=wency@cn.fujitsu.com \
--cc=amit.shah@redhat.com \
--cc=avi@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.