Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/20/2012 11:45 PM, Gleb Natapov Wrote:
On Tue, Mar 20, 2012 at 05:59:16PM +0800, Wen Congyang wrote:
At 03/19/2012 03:33 PM, Wen Congyang Wrote:
At 03/08/2012 03:57 PM, 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.
Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is crashed. If management
app does not do auto dump, the guest's user can do dump by hand if
he sees the guest is paniced.
I touch the hypervisor instead of using virtio-serial, because
1. it is simple
2. the virtio-serial is an optional device, and the guest may
not have such device.
Changes from v2 to v3:
1. correct spelling
Changes from v1 to v2:
1. split up host and guest-side changes
2. introduce new request flag to avoid changing return values.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi all:
we neet this feature, but we don't decide how to implement it.
We have two solution:
1. use vmcall
2. use virtio-serial.
I will not change this patch set before we decide how to do it.
Can we make a decision recent days?
Anybody can decide which solution to use?
To make an informed decision we need to have at least raw idea how
virtio-serial variant will look.
We have three solutions now:
1. use vmcall
2. use I/O port
3. use virtio-serial
I write a sample patch of solution 2 and 3:
patch 1: solution 2
patch 2: solution 3
Note, ther are only sample patches, and it can work. I send them, so we
can decide which solution will be used.
Thanks
Wen Congyang
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From 2c819655982a0b3043892e994fb87fd44fdca686 Mon Sep 17 00:00:00 2001
From: Wen Congyang we...@cn.fujitsu.com
Date: Tue, 17 Apr 2012 10:44:40 +0800
Subject: [PATCH] kvm: notify host when guest panicked
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
---
arch/ia64/include/asm/kvm_para.h|5 +
arch/powerpc/include/asm/kvm_para.h |5 +
arch/s390/include/asm/kvm_para.h|5 +
arch/x86/include/asm/kvm_para.h |7 +++
arch/x86/kernel/kvm.c | 14 ++
include/linux/kvm_para.h| 13 +
6 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/arch/ia64/include/asm/kvm_para.h b/arch/ia64/include/asm/kvm_para.h
index 1588aee..a890096 100644
--- a/arch/ia64/include/asm/kvm_para.h
+++ b/arch/ia64/include/asm/kvm_para.h
@@ -26,6 +26,11 @@ static inline unsigned int kvm_arch_para_features(void)
return 0;
}
+static inline unsigned int kvm_arch_pv_features(void)
+{
+ return 0;
+}
+
#endif
#endif
diff --git a/arch/powerpc/include/asm/kvm_para.h b/arch/powerpc/include/asm/kvm_para.h
index 7b754e7..b5f7c35 100644
--- a/arch/powerpc/include/asm/kvm_para.h
+++ b/arch/powerpc/include/asm/kvm_para.h
@@ -206,6 +206,11 @@ static inline unsigned int kvm_arch_para_features(void)
return r;
}
+static inline unsigned int kvm_arch_pv_features(void)
+{
+ return 0;
+}
+
#endif /* __KERNEL__ */
#endif /* __POWERPC_KVM_PARA_H__ */
diff --git a/arch/s390/include/asm/kvm_para.h b/arch/s390/include/asm/kvm_para.h
index 6964db2..21a8d18 100644
--- a/arch/s390/include/asm/kvm_para.h
+++ b/arch/s390/include/asm/kvm_para.h
@@ -149,6 +149,11 @@ static inline unsigned int kvm_arch_para_features(void)
return 0;
}
+static inline unsigned int kvm_arch_pv_features(void)
+{
+ return 0;
+}
+
#endif
#endif /* __S390_KVM_PARA_H */
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 734c376..02e214a 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -208,6 +208,13 @@ static inline void kvm_disable_steal_time(void)
}
#endif
+#define KVM_PV_PORT (0x505UL)
+
+static inline unsigned int kvm_arch_pv_features(void)
+{
+ return inl(KVM_PV_PORT);
+}
+
#endif /* __KERNEL__ */
#endif /* _ASM_X86_KVM_PARA_H */
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index b8ba6e4..adfde45 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -335,6 +335,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)
+{
+ outl(KVM_PV_PANICKED, KVM_PV_PORT);
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block kvm_pv_panic_nb = {
+ .notifier_call = kvm_pv_panic_notify,
+};
+
static u64 kvm_steal_clock(int cpu)
{
u64 steal;
@@ -421,6 +432,9 @@ void
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/19/2012 03:33 PM, Wen Congyang Wrote: At 03/08/2012 03:57 PM, 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. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced. I touch the hypervisor instead of using virtio-serial, because 1. it is simple 2. the virtio-serial is an optional device, and the guest may not have such device. Changes from v2 to v3: 1. correct spelling Changes from v1 to v2: 1. split up host and guest-side changes 2. introduce new request flag to avoid changing return values. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi all: we neet this feature, but we don't decide how to implement it. We have two solution: 1. use vmcall 2. use virtio-serial. Hi, all There are three solutions now: 1. use vmcall 2. use I/O port 3. use virtio-serial. I think 1 and 2 are more simple than 3. I am reading virtio-serial's driver recent days. It seems that if the virtio serial port is not opened at the host side, the data writen into this port will be discarded, and we will have no chance to know the guest is panicked. To Amit: Can we write message to a virtio serial port like this directly in the kernel space? send_buf(panicked_port, message, message's length, true); if port-outvq_full is true, is it OK to do this? Thanks Wen Congyang I will not change this patch set before we decide how to do it. Can we make a decision recent days? Thanks Wen Congyang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On (Mon) 02 Apr 2012 [18:05:45], Wen Congyang wrote: At 03/19/2012 03:33 PM, Wen Congyang Wrote: At 03/08/2012 03:57 PM, 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. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced. I touch the hypervisor instead of using virtio-serial, because 1. it is simple 2. the virtio-serial is an optional device, and the guest may not have such device. Changes from v2 to v3: 1. correct spelling Changes from v1 to v2: 1. split up host and guest-side changes 2. introduce new request flag to avoid changing return values. Hi all: we neet this feature, but we don't decide how to implement it. We have two solution: 1. use vmcall 2. use virtio-serial. Hi, all There are three solutions now: 1. use vmcall 2. use I/O port 3. use virtio-serial. I think 1 and 2 are more simple than 3. I am reading virtio-serial's driver recent days. It seems that if the virtio serial port is not opened at the host side, the data writen into this port will be discarded, and we will have no chance to know the guest is panicked. The qemu-side implementation should exist within qemu itself; i.e. the consumer of the data from the kernel-side will always have a listener. In this case, you don't have to worry about port not being opened on the host side. To Amit: Can we write message to a virtio serial port like this directly in the kernel space? As I had mentioned earlier, an in-kernel API is currently missing, but it will be very simple to add one. send_buf(panicked_port, message, message's length, true); if port-outvq_full is true, is it OK to do this? port-outvq_full means guest has sent out data to the host, but the host has not consumed the data yet, and has not released the buffers back to the guest. If you indeed reach such a situation (essentially you should never, there are enough buffers already to account for scheduling delays), then newer data will be discarded, or you will have to wait to write the newer data till the host-side frees up buffers in the virtqueues. This isn't really different from other approaches -- if you use a shared buffer between guest and host, and if the guest has new data before the host has had a chance to read off the older buffer contents, you either overwrite or wait for the host to read the older stuff. Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 21, 2012 at 08:56:03AM +0800, Wen Congyang wrote: At 03/20/2012 11:45 PM, Gleb Natapov Wrote: On Tue, Mar 20, 2012 at 05:59:16PM +0800, Wen Congyang wrote: At 03/19/2012 03:33 PM, Wen Congyang Wrote: At 03/08/2012 03:57 PM, 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. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced. I touch the hypervisor instead of using virtio-serial, because 1. it is simple 2. the virtio-serial is an optional device, and the guest may not have such device. Changes from v2 to v3: 1. correct spelling Changes from v1 to v2: 1. split up host and guest-side changes 2. introduce new request flag to avoid changing return values. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi all: we neet this feature, but we don't decide how to implement it. We have two solution: 1. use vmcall 2. use virtio-serial. I will not change this patch set before we decide how to do it. Can we make a decision recent days? Anybody can decide which solution to use? To make an informed decision we need to have at least raw idea how virtio-serial variant will look. Hmm, I think we can do this: 1. reset the virtio-serial device or reset the port we use to notice the host that guest is panicked. 2. write some specific messages to the port So the port should have fixed name. If this port is opened by the userspace before the guest is paniced, I am not sure whether we can use it(because a port only can be opened once at the same time). Yes, IMO we should dedicate one virtio-serial port for panic notifications. Just like we dedicate one for a console. We cannot call any function in the module, so we may need to write a simple driver for virtio-serial(like diskdump's disk driver). netconsole uses standard NIC drivers in polling mode to send OOPSes over the network and it mostly works. So I think using virtio-serial driver is not out of question, but with IRQ disabled of course. I donot know how to implement it now. But I guess that it may be complicated. Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying panic happened, like sending stack traces on all cpus for instance. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/21/2012 05:11 PM, Gleb Natapov Wrote: On Wed, Mar 21, 2012 at 08:56:03AM +0800, Wen Congyang wrote: At 03/20/2012 11:45 PM, Gleb Natapov Wrote: On Tue, Mar 20, 2012 at 05:59:16PM +0800, Wen Congyang wrote: At 03/19/2012 03:33 PM, Wen Congyang Wrote: At 03/08/2012 03:57 PM, 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. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced. I touch the hypervisor instead of using virtio-serial, because 1. it is simple 2. the virtio-serial is an optional device, and the guest may not have such device. Changes from v2 to v3: 1. correct spelling Changes from v1 to v2: 1. split up host and guest-side changes 2. introduce new request flag to avoid changing return values. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi all: we neet this feature, but we don't decide how to implement it. We have two solution: 1. use vmcall 2. use virtio-serial. I will not change this patch set before we decide how to do it. Can we make a decision recent days? Anybody can decide which solution to use? To make an informed decision we need to have at least raw idea how virtio-serial variant will look. Hmm, I think we can do this: 1. reset the virtio-serial device or reset the port we use to notice the host that guest is panicked. 2. write some specific messages to the port So the port should have fixed name. If this port is opened by the userspace before the guest is paniced, I am not sure whether we can use it(because a port only can be opened once at the same time). Yes, IMO we should dedicate one virtio-serial port for panic notifications. Just like we dedicate one for a console. We cannot call any function in the module, so we may need to write a simple driver for virtio-serial(like diskdump's disk driver). netconsole uses standard NIC drivers in polling mode to send OOPSes over the network and it mostly works. So I think using virtio-serial driver is not out of question, but with IRQ disabled of course. The code for netconsole is in which file? Another question: we cannot call the function in the module directly in the kernel. I donot know how to implement it now. But I guess that it may be complicated. Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying panic happened, like sending stack traces on all cpus for instance. If we implement it by virtio-serial, I agree with passing more useful message to host. Thanks Wen Congyang -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 21, 2012 at 05:35:49PM +0800, Wen Congyang wrote: At 03/21/2012 05:11 PM, Gleb Natapov Wrote: On Wed, Mar 21, 2012 at 08:56:03AM +0800, Wen Congyang wrote: At 03/20/2012 11:45 PM, Gleb Natapov Wrote: On Tue, Mar 20, 2012 at 05:59:16PM +0800, Wen Congyang wrote: At 03/19/2012 03:33 PM, Wen Congyang Wrote: At 03/08/2012 03:57 PM, 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. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced. I touch the hypervisor instead of using virtio-serial, because 1. it is simple 2. the virtio-serial is an optional device, and the guest may not have such device. Changes from v2 to v3: 1. correct spelling Changes from v1 to v2: 1. split up host and guest-side changes 2. introduce new request flag to avoid changing return values. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi all: we neet this feature, but we don't decide how to implement it. We have two solution: 1. use vmcall 2. use virtio-serial. I will not change this patch set before we decide how to do it. Can we make a decision recent days? Anybody can decide which solution to use? To make an informed decision we need to have at least raw idea how virtio-serial variant will look. Hmm, I think we can do this: 1. reset the virtio-serial device or reset the port we use to notice the host that guest is panicked. 2. write some specific messages to the port So the port should have fixed name. If this port is opened by the userspace before the guest is paniced, I am not sure whether we can use it(because a port only can be opened once at the same time). Yes, IMO we should dedicate one virtio-serial port for panic notifications. Just like we dedicate one for a console. We cannot call any function in the module, so we may need to write a simple driver for virtio-serial(like diskdump's disk driver). netconsole uses standard NIC drivers in polling mode to send OOPSes over the network and it mostly works. So I think using virtio-serial driver is not out of question, but with IRQ disabled of course. The code for netconsole is in which file? drivers/net/netconsole.c naturally. Another question: we cannot call the function in the module directly in the kernel. True I think. netconsole and actual NIC driver have a layer of abstraction between them. Modules can call functions from other modules. Your module can register to panic_notifier_list (like IPMI does) and call functions from virtio-serial. Or panic handling can be added directly to virtio-serial since it will have to be modified anyway. Something like netpoll API will have to be added to it. I donot know how to implement it now. But I guess that it may be complicated. Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying panic happened, like sending stack traces on all cpus for instance. If we implement it by virtio-serial, I agree with passing more useful message to host. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying panic happened, like sending stack traces on all cpus for instance. I doubt that's the best example, unfortunately. The IPMI event log has limited space and it has to be send a little piece at a time since each log entry is 14 bytes. It just prints the panic string, nothing else. Not that it isn't useful, it has saved my butt before. You have lots of interesting options with paravirtualization. You could, for instance, create a console driver that delivered all console output efficiently through a hypercall. That would be really easy. Or, as you mention, a custom way to deliver panic information. Collecting information like stack traces would be harder to accomplish, as I don't think there is currently a way to get it except by sending it to printk. -corey -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 21, 2012 at 11:18:16AM -0500, Corey Minyard wrote: Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying panic happened, like sending stack traces on all cpus for instance. I doubt that's the best example, unfortunately. The IPMI event log has limited space and it has to be send a little piece at a time since each log entry is 14 bytes. It just prints the panic string, nothing else. Not that it isn't useful, it has saved my butt before. I gave ipmi example just to show that others do complex things on panic, not as an example of what we should do on a guest panic. You have lots of interesting options with paravirtualization. You could, for instance, create a console driver that delivered all console output efficiently through a hypercall. That would be really easy. Or, as you mention, a custom way to deliver panic information. Collecting information like stack traces would be harder to accomplish, as I don't think there is currently a way to get it except by sending it to printk. Why using hypercall for that though? You can do that with virtio-console. Make it zero config: virtio-console detected - send console output there. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On 03/21/2012 06:18 PM, Corey Minyard wrote: Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying panic happened, like sending stack traces on all cpus for instance. I doubt that's the best example, unfortunately. The IPMI event log has limited space and it has to be send a little piece at a time since each log entry is 14 bytes. It just prints the panic string, nothing else. Not that it isn't useful, it has saved my butt before. You have lots of interesting options with paravirtualization. You could, for instance, create a console driver that delivered all console output efficiently through a hypercall. That would be really easy. Or, as you mention, a custom way to deliver panic information. Collecting information like stack traces would be harder to accomplish, as I don't think there is currently a way to get it except by sending it to printk. That already exists; virtio-console (or serial console emulation) can do the job. In fact the feature can be implemented 100% host side by searching for a panic string signature in the console logs. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 21, 2012 at 06:25:16PM +0200, Avi Kivity wrote: On 03/21/2012 06:18 PM, Corey Minyard wrote: Look at drivers/char/ipmi/ipmi_msghandler.c. It has code to send panic event over IMPI. The code is pretty complex. Of course if we a going to implement something more complex than simple hypercall for panic notification we better do something more interesting with it than just saying panic happened, like sending stack traces on all cpus for instance. I doubt that's the best example, unfortunately. The IPMI event log has limited space and it has to be send a little piece at a time since each log entry is 14 bytes. It just prints the panic string, nothing else. Not that it isn't useful, it has saved my butt before. You have lots of interesting options with paravirtualization. You could, for instance, create a console driver that delivered all console output efficiently through a hypercall. That would be really easy. Or, as you mention, a custom way to deliver panic information. Collecting information like stack traces would be harder to accomplish, as I don't think there is currently a way to get it except by sending it to printk. That already exists; virtio-console (or serial console emulation) can do the job. In fact the feature can be implemented 100% host side by searching for a panic string signature in the console logs. You can even go one better and search for the panic string in the guest memory directly, which is what virt-dmesg does :-) http://people.redhat.com/~rjones/virt-dmesg/ Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On 03/21/2012 07:04 PM, Daniel P. Berrange wrote: In fact the feature can be implemented 100% host side by searching for a panic string signature in the console logs. You can even go one better and search for the panic string in the guest memory directly, which is what virt-dmesg does :-) http://people.redhat.com/~rjones/virt-dmesg/ -ETOOHACKY Any guest change will break this, no? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On 2012-03-21 18:34, Avi Kivity wrote: On 03/21/2012 07:04 PM, Daniel P. Berrange wrote: In fact the feature can be implemented 100% host side by searching for a panic string signature in the console logs. You can even go one better and search for the panic string in the guest memory directly, which is what virt-dmesg does :-) http://people.redhat.com/~rjones/virt-dmesg/ -ETOOHACKY Any guest change will break this, no? /me has a simple python script (a few ten lines) to do this during runtime (kgdb, qemu gdbstub) or post-portem (gdb -c vmcore). Ideally, that will once come with the Linux sources where it can be kept in sync with the kernel data structures. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/19/2012 03:33 PM, Wen Congyang Wrote: At 03/08/2012 03:57 PM, 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. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced. I touch the hypervisor instead of using virtio-serial, because 1. it is simple 2. the virtio-serial is an optional device, and the guest may not have such device. Changes from v2 to v3: 1. correct spelling Changes from v1 to v2: 1. split up host and guest-side changes 2. introduce new request flag to avoid changing return values. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi all: we neet this feature, but we don't decide how to implement it. We have two solution: 1. use vmcall 2. use virtio-serial. I will not change this patch set before we decide how to do it. Can we make a decision recent days? Anybody can decide which solution to use? Thanks Wen Congyang Thanks Wen Congyang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On Tue, Mar 20, 2012 at 05:59:16PM +0800, Wen Congyang wrote: At 03/19/2012 03:33 PM, Wen Congyang Wrote: At 03/08/2012 03:57 PM, 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. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced. I touch the hypervisor instead of using virtio-serial, because 1. it is simple 2. the virtio-serial is an optional device, and the guest may not have such device. Changes from v2 to v3: 1. correct spelling Changes from v1 to v2: 1. split up host and guest-side changes 2. introduce new request flag to avoid changing return values. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi all: we neet this feature, but we don't decide how to implement it. We have two solution: 1. use vmcall 2. use virtio-serial. I will not change this patch set before we decide how to do it. Can we make a decision recent days? Anybody can decide which solution to use? To make an informed decision we need to have at least raw idea how virtio-serial variant will look. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/20/2012 11:45 PM, Gleb Natapov Wrote: On Tue, Mar 20, 2012 at 05:59:16PM +0800, Wen Congyang wrote: At 03/19/2012 03:33 PM, Wen Congyang Wrote: At 03/08/2012 03:57 PM, 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. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced. I touch the hypervisor instead of using virtio-serial, because 1. it is simple 2. the virtio-serial is an optional device, and the guest may not have such device. Changes from v2 to v3: 1. correct spelling Changes from v1 to v2: 1. split up host and guest-side changes 2. introduce new request flag to avoid changing return values. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi all: we neet this feature, but we don't decide how to implement it. We have two solution: 1. use vmcall 2. use virtio-serial. I will not change this patch set before we decide how to do it. Can we make a decision recent days? Anybody can decide which solution to use? To make an informed decision we need to have at least raw idea how virtio-serial variant will look. Hmm, I think we can do this: 1. reset the virtio-serial device or reset the port we use to notice the host that guest is panicked. 2. write some specific messages to the port So the port should have fixed name. If this port is opened by the userspace before the guest is paniced, I am not sure whether we can use it(because a port only can be opened once at the same time). We cannot call any function in the module, so we may need to write a simple driver for virtio-serial(like diskdump's disk driver). I donot know how to implement it now. But I guess that it may be complicated. Thanks Wen Congyang -- Gleb. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/08/2012 03:57 PM, 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. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced. I touch the hypervisor instead of using virtio-serial, because 1. it is simple 2. the virtio-serial is an optional device, and the guest may not have such device. Changes from v2 to v3: 1. correct spelling Changes from v1 to v2: 1. split up host and guest-side changes 2. introduce new request flag to avoid changing return values. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi all: we neet this feature, but we don't decide how to implement it. We have two solution: 1. use vmcall 2. use virtio-serial. I will not change this patch set before we decide how to do it. Can we make a decision recent days? Thanks Wen Congyang -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/15/2012 02:46 AM, Eric Northup Wrote: On Wed, Mar 14, 2012 at 6:25 AM, Gleb Natapov g...@redhat.com wrote: On Wed, Mar 14, 2012 at 03:16:05PM +0200, Avi Kivity wrote: On 03/14/2012 03:14 PM, Gleb Natapov wrote: On Wed, Mar 14, 2012 at 03:07:46PM +0200, Avi Kivity wrote: On 03/14/2012 01:11 PM, Wen Congyang wrote: 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? Are you willing to try it out and see how complicated it really is? While it's more complicated, it's also more flexible. You can communicate the panic message, whether the guest is attempting a kdump and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses. hypercall can take arguments to achieve the same. It has to be designed in advance; and every time we notice something's missing we have to update the host kernel. We and in the designed stage now. Not to late to design something flexible :) Panic hypercall can take GPA of a buffer where host puts panic info as a parameter. This buffer can be read by QEMU and passed to management. If a host kernel change is in the works, I think it might be cleanest to have the host kernel export a new kind of VCPU exit for unhandled-by-KVM hypercalls. Then usermode can respond to the hypercall as appropriate. This would permit adding or changing future hypercalls without host kernel changes. Guest panic is almost the definition of not-a-fast-path, and so what's the reason to handle it in the host kernel. Punting to user-space wouldn't be a magic bullet for getting good interfaces designed, but in my opinion it is a better place to be doing them. Do you mean that: the guest execute vmcall instruction, and the host kernel exits to userspace. The userspace will deal with the vmexit? Thanks Wen Congyang -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 14, 2012 at 11:46:08AM -0700, Eric Northup wrote: On Wed, Mar 14, 2012 at 6:25 AM, Gleb Natapov g...@redhat.com wrote: On Wed, Mar 14, 2012 at 03:16:05PM +0200, Avi Kivity wrote: On 03/14/2012 03:14 PM, Gleb Natapov wrote: On Wed, Mar 14, 2012 at 03:07:46PM +0200, Avi Kivity wrote: On 03/14/2012 01:11 PM, Wen Congyang wrote: 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? Are you willing to try it out and see how complicated it really is? While it's more complicated, it's also more flexible. You can communicate the panic message, whether the guest is attempting a kdump and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses. hypercall can take arguments to achieve the same. It has to be designed in advance; and every time we notice something's missing we have to update the host kernel. We and in the designed stage now. Not to late to design something flexible :) Panic hypercall can take GPA of a buffer where host puts panic info as a parameter. This buffer can be read by QEMU and passed to management. If a host kernel change is in the works, I think it might be cleanest to have the host kernel export a new kind of VCPU exit for unhandled-by-KVM hypercalls. Then usermode can respond to the hypercall as appropriate. This would permit adding or changing future hypercalls without host kernel changes. There was such vm exit (KVM_EXIT_HYPERCALL), but it was deemed to be a bad idea. Guest panic is almost the definition of not-a-fast-path, and so what's the reason to handle it in the host kernel. The only handling that kernel does is maps hypercall to panic exit. Punting to user-space wouldn't be a magic bullet for getting good interfaces designed, but in my opinion it is a better place to be doing them. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On 2012-03-15 11:39, Gleb Natapov wrote: On Wed, Mar 14, 2012 at 11:46:08AM -0700, Eric Northup wrote: On Wed, Mar 14, 2012 at 6:25 AM, Gleb Natapov g...@redhat.com wrote: On Wed, Mar 14, 2012 at 03:16:05PM +0200, Avi Kivity wrote: On 03/14/2012 03:14 PM, Gleb Natapov wrote: On Wed, Mar 14, 2012 at 03:07:46PM +0200, Avi Kivity wrote: On 03/14/2012 01:11 PM, Wen Congyang wrote: 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? Are you willing to try it out and see how complicated it really is? While it's more complicated, it's also more flexible. You can communicate the panic message, whether the guest is attempting a kdump and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses. hypercall can take arguments to achieve the same. It has to be designed in advance; and every time we notice something's missing we have to update the host kernel. We and in the designed stage now. Not to late to design something flexible :) Panic hypercall can take GPA of a buffer where host puts panic info as a parameter. This buffer can be read by QEMU and passed to management. If a host kernel change is in the works, I think it might be cleanest to have the host kernel export a new kind of VCPU exit for unhandled-by-KVM hypercalls. Then usermode can respond to the hypercall as appropriate. This would permit adding or changing future hypercalls without host kernel changes. There was such vm exit (KVM_EXIT_HYPERCALL), but it was deemed to be a bad idea. BTW, this would help a lot in emulating hypercalls of other hypervisors (or of KVM's VAPIC in the absence of in-kernel irqchip - I had to jump through hoops therefore) in user space. Not all those hypercall handlers actually have to reside in the KVM module. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On 03/15/2012 01:25 PM, Jan Kiszka wrote: There was such vm exit (KVM_EXIT_HYPERCALL), but it was deemed to be a bad idea. BTW, this would help a lot in emulating hypercalls of other hypervisors (or of KVM's VAPIC in the absence of in-kernel irqchip - I had to jump through hoops therefore) in user space. Not all those hypercall handlers actually have to reside in the KVM module. That is true. On the other hand the hypercall ABI might go to pieces if there was no central implementation. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/13/2012 06:47 PM, Avi Kivity Wrote: On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. I donot know how to use virtio-serial. I start vm like this: qemu ...\ -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=port1 ... You said that there are too many channels. Does it mean /tmp/foo is a channel? Thanks Wen Congyang -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On 03/14/2012 10:29 AM, Wen Congyang wrote: At 03/13/2012 06:47 PM, Avi Kivity Wrote: On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. I donot know how to use virtio-serial. I don't either, copying Amit. I start vm like this: qemu ...\ -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=port1 ... You said that there are too many channels. Does it mean /tmp/foo is a channel? Probably. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On (Wed) 14 Mar 2012 [16:29:50], Wen Congyang wrote: At 03/13/2012 06:47 PM, Avi Kivity Wrote: On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. I donot know how to use virtio-serial. I start vm like this: qemu ...\ -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=port1 ... This is sufficient. On the host, you can open /tmp/foo using a custom program or nc (nc -U /tmp/foo). On the guest, you can just open /dev/virtio-ports/port1 and read/write into it. See the following links for more details. https://fedoraproject.org/wiki/Features/VirtioSerial#How_To_Test http://www.linux-kvm.org/page/Virtio-serial_API You said that there are too many channels. Does it mean /tmp/foo is a channel? You can have several such -device virtserialport. The -device part describes what the guest will see. The -chardev part ties that to the host-side part of the channel. /tmp/foo is the host end-point for the channel, in the example above, and /dev/virtio-ports/port1 is the guest-side end-point. Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/14/2012 05:24 PM, Avi Kivity Wrote: On 03/14/2012 10:29 AM, Wen Congyang wrote: At 03/13/2012 06:47 PM, Avi Kivity Wrote: On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. I donot know how to use virtio-serial. I don't either, copying Amit. I start vm like this: qemu ...\ -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=port1 ... You said that there are too many channels. Does it mean /tmp/foo is a channel? Probably. Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right? 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. Thanks Wen Congyang -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/14/2012 05:51 PM, Amit Shah Wrote: On (Wed) 14 Mar 2012 [16:29:50], Wen Congyang wrote: At 03/13/2012 06:47 PM, Avi Kivity Wrote: On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. I donot know how to use virtio-serial. I start vm like this: qemu ...\ -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=port1 ... This is sufficient. On the host, you can open /tmp/foo using a custom program or nc (nc -U /tmp/foo). On the guest, you can just open /dev/virtio-ports/port1 and read/write into it. I have two questions: 1. does it OK to open this device when the guest is panicked? 2. how to prevent the userspace's program using this device? Thanks Wen Congyang See the following links for more details. https://fedoraproject.org/wiki/Features/VirtioSerial#How_To_Test http://www.linux-kvm.org/page/Virtio-serial_API You said that there are too many channels. Does it mean /tmp/foo is a channel? You can have several such -device virtserialport. The -device part describes what the guest will see. The -chardev part ties that to the host-side part of the channel. /tmp/foo is the host end-point for the channel, in the example above, and /dev/virtio-ports/port1 is the guest-side end-point. Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On 03/14/2012 11:53 AM, Wen Congyang wrote: At 03/14/2012 05:24 PM, Avi Kivity Wrote: On 03/14/2012 10:29 AM, Wen Congyang wrote: At 03/13/2012 06:47 PM, Avi Kivity Wrote: On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. I donot know how to use virtio-serial. I don't either, copying Amit. I start vm like this: qemu ...\ -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=port1 ... You said that there are too many channels. Does it mean /tmp/foo is a channel? Probably. Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right? Right. 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. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On 03/14/2012 12:04 PM, Wen Congyang wrote: This is sufficient. On the host, you can open /tmp/foo using a custom program or nc (nc -U /tmp/foo). On the guest, you can just open /dev/virtio-ports/port1 and read/write into it. I have two questions: 1. does it OK to open this device when the guest is panicked? On panic, I think it's best to reset the device and drive it directly from the panic handler. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/14/2012 06:07 PM, Avi Kivity Wrote: On 03/14/2012 11:53 AM, Wen Congyang wrote: At 03/14/2012 05:24 PM, Avi Kivity Wrote: On 03/14/2012 10:29 AM, Wen Congyang wrote: At 03/13/2012 06:47 PM, Avi Kivity Wrote: On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. I donot know how to use virtio-serial. I don't either, copying Amit. I start vm like this: qemu ...\ -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=port1 ... You said that there are too many channels. Does it mean /tmp/foo is a channel? Probably. Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right? Right. 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. Thanks Wen Congyang -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
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. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On (Wed) 14 Mar 2012 [17:53:00], Wen Congyang wrote: At 03/14/2012 05:24 PM, Avi Kivity Wrote: On 03/14/2012 10:29 AM, Wen Congyang wrote: At 03/13/2012 06:47 PM, Avi Kivity Wrote: On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. I donot know how to use virtio-serial. I don't either, copying Amit. I start vm like this: qemu ...\ -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=port1 ... You said that there are too many channels. Does it mean /tmp/foo is a channel? Probably. Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right? Depends on how you want to use it. It could be the kernel, or it could be a userspace program which monitors syslogs for panic information and passes on that info to the virtio-serial channel. 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. Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user. Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On (Wed) 14 Mar 2012 [18:04:40], Wen Congyang wrote: At 03/14/2012 05:51 PM, Amit Shah Wrote: On (Wed) 14 Mar 2012 [16:29:50], Wen Congyang wrote: At 03/13/2012 06:47 PM, Avi Kivity Wrote: On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. I donot know how to use virtio-serial. I start vm like this: qemu ...\ -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=port1 ... This is sufficient. On the host, you can open /tmp/foo using a custom program or nc (nc -U /tmp/foo). On the guest, you can just open /dev/virtio-ports/port1 and read/write into it. I have two questions: 1. does it OK to open this device when the guest is panicked? Depends on what kind of panic it is. If the guest can continue operations inspite of the panic, it will be possible to write out the data. 2. how to prevent the userspace's program using this device? Mentioned in previous reply. BTW: an in-kernel API for reading/writing to ports isn't implemented yet, because there's no user for it as of now. If you want to write from the kernel to the host, there are trivial additions to the code necessary. (However, I think it's better to do the writing from userspace instead from the kernel itself). Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 14, 2012 at 04:10:04PM +0530, Amit Shah wrote: On (Wed) 14 Mar 2012 [18:04:40], Wen Congyang wrote: At 03/14/2012 05:51 PM, Amit Shah Wrote: On (Wed) 14 Mar 2012 [16:29:50], Wen Congyang wrote: At 03/13/2012 06:47 PM, Avi Kivity Wrote: On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. I donot know how to use virtio-serial. I start vm like this: qemu ...\ -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=port1 ... This is sufficient. On the host, you can open /tmp/foo using a custom program or nc (nc -U /tmp/foo). On the guest, you can just open /dev/virtio-ports/port1 and read/write into it. I have two questions: 1. does it OK to open this device when the guest is panicked? Depends on what kind of panic it is. If the guest can continue operations inspite of the panic, it will be possible to write out the data. 2. how to prevent the userspace's program using this device? Mentioned in previous reply. BTW: an in-kernel API for reading/writing to ports isn't implemented yet, because there's no user for it as of now. If you want to write from the kernel to the host, there are trivial additions to the code necessary. (However, I think it's better to do the writing from userspace instead from the kernel itself). In case of panic notifier this is out of question. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
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. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
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. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/14/2012 06:37 PM, Amit Shah Wrote: On (Wed) 14 Mar 2012 [17:53:00], Wen Congyang wrote: At 03/14/2012 05:24 PM, Avi Kivity Wrote: On 03/14/2012 10:29 AM, Wen Congyang wrote: At 03/13/2012 06:47 PM, Avi Kivity Wrote: On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. I donot know how to use virtio-serial. I don't either, copying Amit. I start vm like this: qemu ...\ -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=port1 ... You said that there are too many channels. Does it mean /tmp/foo is a channel? Probably. Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right? Depends on how you want to use it. It could be the kernel, or it could be a userspace program which monitors syslogs for panic information and passes on that info to the virtio-serial channel. When the kernel is panicked, we cannot use userspace program. 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. Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user. We should also prevent root user writing message to this channel if it is used for panicked notification. Thanks Wen Congyang Amit -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 14, 2012 at 06:52:07PM +0800, Wen Congyang wrote: At 03/14/2012 06:37 PM, Amit Shah Wrote: On (Wed) 14 Mar 2012 [17:53:00], Wen Congyang wrote: At 03/14/2012 05:24 PM, Avi Kivity Wrote: On 03/14/2012 10:29 AM, Wen Congyang wrote: At 03/13/2012 06:47 PM, Avi Kivity Wrote: On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. I donot know how to use virtio-serial. I don't either, copying Amit. I start vm like this: qemu ...\ -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=port1 ... You said that there are too many channels. Does it mean /tmp/foo is a channel? Probably. Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right? Depends on how you want to use it. It could be the kernel, or it could be a userspace program which monitors syslogs for panic information and passes on that info to the virtio-serial channel. When the kernel is panicked, we cannot use userspace program. 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. Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user. We should also prevent root user writing message to this channel if it is used for panicked notification. Why? Root user can also call panic hypercall if he wishes so. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On 03/14/2012 12:52 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. Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user. We should also prevent root user writing message to this channel if it is used for panicked notification. Why? root can easily cause a panic. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/14/2012 06:52 PM, Gleb Natapov Wrote: On Wed, Mar 14, 2012 at 06:52:07PM +0800, Wen Congyang wrote: At 03/14/2012 06:37 PM, Amit Shah Wrote: On (Wed) 14 Mar 2012 [17:53:00], Wen Congyang wrote: At 03/14/2012 05:24 PM, Avi Kivity Wrote: On 03/14/2012 10:29 AM, Wen Congyang wrote: At 03/13/2012 06:47 PM, Avi Kivity Wrote: On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. I donot know how to use virtio-serial. I don't either, copying Amit. I start vm like this: qemu ...\ -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=port1 ... You said that there are too many channels. Does it mean /tmp/foo is a channel? Probably. Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right? Depends on how you want to use it. It could be the kernel, or it could be a userspace program which monitors syslogs for panic information and passes on that info to the virtio-serial channel. When the kernel is panicked, we cannot use userspace program. 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. Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user. We should also prevent root user writing message to this channel if it is used for panicked notification. Why? Root user can also call panic hypercall if he wishes so. IIRC, the instruction vmcall needs to run on ring0. The root user is in ring3. Thanks Wen Congyang -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/14/2012 06:52 PM, Avi Kivity Wrote: On 03/14/2012 12:52 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. Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user. We should also prevent root user writing message to this channel if it is used for panicked notification. Why? root can easily cause a panic. root user can write the same message to virtio-serial while the guest is running... Thanks Wen Congyang -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 14, 2012 at 03:21:14PM +0530, Amit Shah wrote: On (Wed) 14 Mar 2012 [16:29:50], Wen Congyang wrote: At 03/13/2012 06:47 PM, Avi Kivity Wrote: On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. I donot know how to use virtio-serial. I start vm like this: qemu ...\ -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=port1 ... This is sufficient. On the host, you can open /tmp/foo using a custom program or nc (nc -U /tmp/foo). On the guest, you can just open /dev/virtio-ports/port1 and read/write into it. See the following links for more details. https://fedoraproject.org/wiki/Features/VirtioSerial#How_To_Test http://www.linux-kvm.org/page/Virtio-serial_API You said that there are too many channels. Does it mean /tmp/foo is a channel? You can have several such -device virtserialport. The -device part describes what the guest will see. The -chardev part ties that to the host-side part of the channel. /tmp/foo is the host end-point for the channel, in the example above, and /dev/virtio-ports/port1 is the guest-side end-point. If we do choose to use virtio-serial for panics (which I don't think we should), then we should not expose it in the host filesystem. The host side should be a virtual chardev backend internal to QEMU, in the same way that 'spicevmc' is handled. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On (Wed) 14 Mar 2012 [18:52:07], Wen Congyang wrote: At 03/14/2012 06:37 PM, Amit Shah Wrote: On (Wed) 14 Mar 2012 [17:53:00], Wen Congyang wrote: At 03/14/2012 05:24 PM, Avi Kivity Wrote: On 03/14/2012 10:29 AM, Wen Congyang wrote: At 03/13/2012 06:47 PM, Avi Kivity Wrote: On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. I donot know how to use virtio-serial. I don't either, copying Amit. I start vm like this: qemu ...\ -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=port1 ... You said that there are too many channels. Does it mean /tmp/foo is a channel? Probably. Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right? Depends on how you want to use it. It could be the kernel, or it could be a userspace program which monitors syslogs for panic information and passes on that info to the virtio-serial channel. When the kernel is panicked, we cannot use userspace program. 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. Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user. We should also prevent root user writing message to this channel if it is used for panicked notification. Well, if you want a particular channel to be write-only by the kernel, that can be arranged as well: just don't expose it in /dev/ at all. Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 14, 2012 at 06:57:59PM +0800, Wen Congyang wrote: At 03/14/2012 06:52 PM, Gleb Natapov Wrote: On Wed, Mar 14, 2012 at 06:52:07PM +0800, Wen Congyang wrote: At 03/14/2012 06:37 PM, Amit Shah Wrote: On (Wed) 14 Mar 2012 [17:53:00], Wen Congyang wrote: At 03/14/2012 05:24 PM, Avi Kivity Wrote: On 03/14/2012 10:29 AM, Wen Congyang wrote: At 03/13/2012 06:47 PM, Avi Kivity Wrote: On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. I donot know how to use virtio-serial. I don't either, copying Amit. I start vm like this: qemu ...\ -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=port1 ... You said that there are too many channels. Does it mean /tmp/foo is a channel? Probably. Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right? Depends on how you want to use it. It could be the kernel, or it could be a userspace program which monitors syslogs for panic information and passes on that info to the virtio-serial channel. When the kernel is panicked, we cannot use userspace program. 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. Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user. We should also prevent root user writing message to this channel if it is used for panicked notification. Why? Root user can also call panic hypercall if he wishes so. IIRC, the instruction vmcall needs to run on ring0. The root user is in ring3. And who will stop the root from loading kernel module? -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 14, 2012 at 06:58:47PM +0800, Wen Congyang wrote: At 03/14/2012 06:52 PM, Avi Kivity Wrote: On 03/14/2012 12:52 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. Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user. We should also prevent root user writing message to this channel if it is used for panicked notification. Why? root can easily cause a panic. root user can write the same message to virtio-serial while the guest is running... Unless you are running a MAC policy which strictly confines the root account, root can cause a kernel panic regardless of virtio-serial permissions in the guest: echo c /proc/sysrq-trigger Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 14, 2012 at 06:58:47PM +0800, Wen Congyang wrote: At 03/14/2012 06:52 PM, Avi Kivity Wrote: On 03/14/2012 12:52 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. Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user. We should also prevent root user writing message to this channel if it is used for panicked notification. Why? root can easily cause a panic. root user can write the same message to virtio-serial while the guest is running... So what? -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/14/2012 06:57 PM, Daniel P. Berrange Wrote: On Wed, Mar 14, 2012 at 03:21:14PM +0530, Amit Shah wrote: On (Wed) 14 Mar 2012 [16:29:50], Wen Congyang wrote: At 03/13/2012 06:47 PM, Avi Kivity Wrote: On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. I donot know how to use virtio-serial. I start vm like this: qemu ...\ -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=port1 ... This is sufficient. On the host, you can open /tmp/foo using a custom program or nc (nc -U /tmp/foo). On the guest, you can just open /dev/virtio-ports/port1 and read/write into it. See the following links for more details. https://fedoraproject.org/wiki/Features/VirtioSerial#How_To_Test http://www.linux-kvm.org/page/Virtio-serial_API You said that there are too many channels. Does it mean /tmp/foo is a channel? You can have several such -device virtserialport. The -device part describes what the guest will see. The -chardev part ties that to the host-side part of the channel. /tmp/foo is the host end-point for the channel, in the example above, and /dev/virtio-ports/port1 is the guest-side end-point. If we do choose to use virtio-serial for panics (which I don't think we should), then we should not expose it in the host filesystem. The host side should be a virtual chardev backend internal to QEMU, in the same way that 'spicevmc' is handled. Yes. But we don't decide to choose which now. I prefer to use vmcall. It is simple and more reliable. Thanks Wen Congyang Regards, Daniel -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/14/2012 06:59 PM, Daniel P. Berrange Wrote: On Wed, Mar 14, 2012 at 06:58:47PM +0800, Wen Congyang wrote: At 03/14/2012 06:52 PM, Avi Kivity Wrote: On 03/14/2012 12:52 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. Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user. We should also prevent root user writing message to this channel if it is used for panicked notification. Why? root can easily cause a panic. root user can write the same message to virtio-serial while the guest is running... Unless you are running a MAC policy which strictly confines the root account, root can cause a kernel panic regardless of virtio-serial permissions in the guest: echo c /proc/sysrq-trigger Yes, root user can cause a kernel panic. But if he writes the same message to virtio-serial, the host will see the guest is panicked while the guest is not panicked. The host is cheated. If we use vmcall, and the user causes a kernel panic, we can also know the guest is panicked. It is the thing what we need. We need to know the guest is panicked, and we donot aware why it is panicked. If the guest is not panicked, and the host think the guest is panicked, it is not the thing we need. Thanks Regards, Daniel -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 14, 2012 at 07:06:50PM +0800, Wen Congyang wrote: At 03/14/2012 06:59 PM, Daniel P. Berrange Wrote: On Wed, Mar 14, 2012 at 06:58:47PM +0800, Wen Congyang wrote: At 03/14/2012 06:52 PM, Avi Kivity Wrote: On 03/14/2012 12:52 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. Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user. We should also prevent root user writing message to this channel if it is used for panicked notification. Why? root can easily cause a panic. root user can write the same message to virtio-serial while the guest is running... Unless you are running a MAC policy which strictly confines the root account, root can cause a kernel panic regardless of virtio-serial permissions in the guest: echo c /proc/sysrq-trigger Yes, root user can cause a kernel panic. But if he writes the same message to virtio-serial, the host will see the guest is panicked while the guest is not panicked. The host is cheated. And why is this a problem? If root in a guest wants to cheat host like that there is no way to stop him. He can load kernel module and do whatever he wants. Management should treat that condition as if guest panicked. If we use vmcall, and the user causes a kernel panic, we can also know the guest is panicked. It is the thing what we need. We need to know the guest is panicked, and we donot aware why it is panicked. If the guest is not panicked, and the host think the guest is panicked, it is not the thing we need. Then you cannot get the thing you need and you can as well stop trying. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/14/2012 06:58 PM, Gleb Natapov Wrote: On Wed, Mar 14, 2012 at 06:57:59PM +0800, Wen Congyang wrote: At 03/14/2012 06:52 PM, Gleb Natapov Wrote: On Wed, Mar 14, 2012 at 06:52:07PM +0800, Wen Congyang wrote: At 03/14/2012 06:37 PM, Amit Shah Wrote: On (Wed) 14 Mar 2012 [17:53:00], Wen Congyang wrote: At 03/14/2012 05:24 PM, Avi Kivity Wrote: On 03/14/2012 10:29 AM, Wen Congyang wrote: At 03/13/2012 06:47 PM, Avi Kivity Wrote: On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. I donot know how to use virtio-serial. I don't either, copying Amit. I start vm like this: qemu ...\ -device virtio-serial \ -chardev socket,path=/tmp/foo,server,nowait,id=foo \ -device virtserialport,chardev=foo,name=port1 ... You said that there are too many channels. Does it mean /tmp/foo is a channel? Probably. Hmm, if we use virtio-serial, the guest kernel writes something into the channel when the os is panicked. Is it right? Depends on how you want to use it. It could be the kernel, or it could be a userspace program which monitors syslogs for panic information and passes on that info to the virtio-serial channel. When the kernel is panicked, we cannot use userspace program. 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. Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user. We should also prevent root user writing message to this channel if it is used for panicked notification. Why? Root user can also call panic hypercall if he wishes so. IIRC, the instruction vmcall needs to run on ring0. The root user is in ring3. And who will stop the root from loading kernel module? Yes, I forgot this. Thanks Wen Congyang -- Gleb. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 14, 2012 at 07:06:50PM +0800, Wen Congyang wrote: At 03/14/2012 06:59 PM, Daniel P. Berrange Wrote: On Wed, Mar 14, 2012 at 06:58:47PM +0800, Wen Congyang wrote: At 03/14/2012 06:52 PM, Avi Kivity Wrote: On 03/14/2012 12:52 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. Access control is via permissions. You can have udev scripts assign whatever uid and gid to the port of your interest. By default, all ports are only accessible to the root user. We should also prevent root user writing message to this channel if it is used for panicked notification. Why? root can easily cause a panic. root user can write the same message to virtio-serial while the guest is running... Unless you are running a MAC policy which strictly confines the root account, root can cause a kernel panic regardless of virtio-serial permissions in the guest: echo c /proc/sysrq-trigger Yes, root user can cause a kernel panic. But if he writes the same message to virtio-serial, the host will see the guest is panicked while the guest is not panicked. The host is cheated. The host mgmt layer must *ALWAYS* expect that any information originating from the guest is bogus. It must never trust the guest info. So regardless of the implementation, you have to expect that the guest might have lied to you about it being crashed. The same is true even of Xen's panic notifier. So if an application is automatically triggering core dumps based on this panic notification, it needs to be aware that the guest can lie and take steps to avoid the guest causing a DOS attack on the host. Most likely by rate limiting the frequency of core dumps per guest, and/or setting a max core dump storage quota per guest. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On 03/14/2012 01:11 PM, Wen Congyang wrote: 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? Are you willing to try it out and see how complicated it really is? While it's more complicated, it's also more flexible. You can communicate the panic message, whether the guest is attempting a kdump and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses. I think the other ones prefer to touch the hypervisor. I understand the sentiment. Your patches are simple and easy. But my feeling is that the kernel has become too complicated already and I'm looking for ways to limit changes. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On 03/14/2012 03:07 PM, Avi Kivity wrote: On 03/14/2012 01:11 PM, Wen Congyang wrote: 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? Are you willing to try it out and see how complicated it really is? While it's more complicated, it's also more flexible. You can communicate the panic message, whether the guest is attempting a kdump and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses. Note, this is similar to how network drivers have a special path (no interrupts) for netconsole output, this is used during panic as well. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 14, 2012 at 03:07:46PM +0200, Avi Kivity wrote: On 03/14/2012 01:11 PM, Wen Congyang wrote: 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? Are you willing to try it out and see how complicated it really is? While it's more complicated, it's also more flexible. You can communicate the panic message, whether the guest is attempting a kdump and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses. hypercall can take arguments to achieve the same. I think the other ones prefer to touch the hypervisor. I understand the sentiment. Your patches are simple and easy. But my feeling is that the kernel has become too complicated already and I'm looking for ways to limit changes. Using virtio-serial will not reduce kernel complexity. Quite contrary since code that will use virtio-serial will be more complicated. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On 03/14/2012 03:14 PM, Gleb Natapov wrote: On Wed, Mar 14, 2012 at 03:07:46PM +0200, Avi Kivity wrote: On 03/14/2012 01:11 PM, Wen Congyang wrote: 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? Are you willing to try it out and see how complicated it really is? While it's more complicated, it's also more flexible. You can communicate the panic message, whether the guest is attempting a kdump and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses. hypercall can take arguments to achieve the same. It has to be designed in advance; and every time we notice something's missing we have to update the host kernel. I think the other ones prefer to touch the hypervisor. I understand the sentiment. Your patches are simple and easy. But my feeling is that the kernel has become too complicated already and I'm looking for ways to limit changes. Using virtio-serial will not reduce kernel complexity. Quite contrary since code that will use virtio-serial will be more complicated. The host kernel is unmodified though. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 14, 2012 at 03:16:05PM +0200, Avi Kivity wrote: On 03/14/2012 03:14 PM, Gleb Natapov wrote: On Wed, Mar 14, 2012 at 03:07:46PM +0200, Avi Kivity wrote: On 03/14/2012 01:11 PM, Wen Congyang wrote: 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? Are you willing to try it out and see how complicated it really is? While it's more complicated, it's also more flexible. You can communicate the panic message, whether the guest is attempting a kdump and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses. hypercall can take arguments to achieve the same. It has to be designed in advance; and every time we notice something's missing we have to update the host kernel. We and in the designed stage now. Not to late to design something flexible :) Panic hypercall can take GPA of a buffer where host puts panic info as a parameter. This buffer can be read by QEMU and passed to management. I think the other ones prefer to touch the hypervisor. I understand the sentiment. Your patches are simple and easy. But my feeling is that the kernel has become too complicated already and I'm looking for ways to limit changes. Using virtio-serial will not reduce kernel complexity. Quite contrary since code that will use virtio-serial will be more complicated. The host kernel is unmodified though. Yes, this is trade-off between complexity in hypervisor and a guest kernel. But in the end we use the same kernel for both. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On Wed, Mar 14, 2012 at 6:25 AM, Gleb Natapov g...@redhat.com wrote: On Wed, Mar 14, 2012 at 03:16:05PM +0200, Avi Kivity wrote: On 03/14/2012 03:14 PM, Gleb Natapov wrote: On Wed, Mar 14, 2012 at 03:07:46PM +0200, Avi Kivity wrote: On 03/14/2012 01:11 PM, Wen Congyang wrote: 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? Are you willing to try it out and see how complicated it really is? While it's more complicated, it's also more flexible. You can communicate the panic message, whether the guest is attempting a kdump and its own recovery or whether it wants the host to do it, etc., you can communicate less severe failures like oopses. hypercall can take arguments to achieve the same. It has to be designed in advance; and every time we notice something's missing we have to update the host kernel. We and in the designed stage now. Not to late to design something flexible :) Panic hypercall can take GPA of a buffer where host puts panic info as a parameter. This buffer can be read by QEMU and passed to management. If a host kernel change is in the works, I think it might be cleanest to have the host kernel export a new kind of VCPU exit for unhandled-by-KVM hypercalls. Then usermode can respond to the hypercall as appropriate. This would permit adding or changing future hypercalls without host kernel changes. Guest panic is almost the definition of not-a-fast-path, and so what's the reason to handle it in the host kernel. Punting the functionality to user-space isn't a magic bullet for getting a good interface designed, but in my opinion it is a better place to be doing this. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/12/2012 06:33 PM, Avi Kivity Wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. Hmm, can we use virtio-serial to talk with not-linux OS? I guess the answer is no. If so, virtio-serial is also used by linux. Another problem is: virtio-serial is available on many deployed versions but the guest must have virtio-serial device. So we cannot know the guest is panicked if it does not have virtio-serial device while the hypercall does not depend on any device. Thanks Wen Congyang -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On 03/13/2012 08:44 AM, Wen Congyang wrote: At 03/12/2012 06:33 PM, Avi Kivity Wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. Hmm, can we use virtio-serial to talk with not-linux OS? I guess the answer is no. If so, virtio-serial is also used by linux. You can use virtio-serial with any guest that has a driver. There are drivers available for Windows. Another problem is: virtio-serial is available on many deployed versions but the guest must have virtio-serial device. So we cannot know the guest is panicked if it does not have virtio-serial device while the hypercall does not depend on any device. The hypercall implementation must exist in the hypervisor. virtio-serial is used by the guest agent, so it's likely to be availalble in all cloud or data center deployments. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. Many management application won't know to make a vioserial device available to all guests they create. Most administrators won't even configure kexec, let alone virtio serial on top of it. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On 03/13/2012 11:18 AM, Daniel P. Berrange wrote: On Mon, Mar 12, 2012 at 12:33:33PM +0200, Avi Kivity wrote: On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. As mentioned before, I don't think virtio-serial is a good fit for this. We want something that is simple guaranteed always available. Using virtio-serial requires significant setup work on both the host and guest. So what? It needs to be done anyway for the guest agent. Many management application won't know to make a vioserial device available to all guests they create. Then they won't know to deal with the panic event either. Most administrators won't even configure kexec, let alone virtio serial on top of it. It should be done by the OS vendor, not the individual admin. The hypercall requires zero host side config, and zero guest side config, which IMHO is what we need for this feature. If it was this one feature, yes. But we keep getting more and more features like that and we bloat the hypervisor. There's a reason we have a host-to-guest channel, we should use it. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/09/2012 09:21 AM, Wen Congyang Wrote: At 03/08/2012 07:13 PM, Avi Kivity Wrote: On 03/08/2012 09:57 AM, 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. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced. I touch the hypervisor instead of using virtio-serial, because 1. it is simple 2. the virtio-serial is an optional device, and the guest may not have such device. Changes from v2 to v3: 1. correct spelling Changes from v1 to v2: 1. split up host and guest-side changes 2. introduce new request flag to avoid changing return values. I see no Documentation/ changes. Do you have any other comments about this patch? What shoude be writen into Documentation/? I read the documents under Documentation/virtual/kvm, not all KVM_EXIT_* are writen in api.txt. In this patch set, I introduce a new exit_reason: KVM_EXIT_GUEST_PANICKED, but I donot know where I should write. What about this? Thanks Wen Congyang Thanks Wen Congyang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On 03/09/2012 03:21 AM, Wen Congyang wrote: Changes from v2 to v3: 1. correct spelling Changes from v1 to v2: 1. split up host and guest-side changes 2. introduce new request flag to avoid changing return values. I see no Documentation/ changes. What shoude be writen into Documentation/? I read the documents under Documentation/virtual/kvm, not all KVM_EXIT_* are writen in api.txt. In this patch set, I introduce a new exit_reason: KVM_EXIT_GUEST_PANICKED, but I donot know where I should write. Describe the exit (why it happens). Also document the new hypercall. If there is no good place for it, start a new file. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On 03/12/2012 11:04 AM, Wen Congyang wrote: Do you have any other comments about this patch? Not really, but I'm not 100% convinced the patch is worthwhile. It's likely to only be used by Linux, which has kexec facilities, and you can put talk to management via virtio-serial and describe the crash in more details than a simple hypercall. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
On 03/08/2012 09:57 AM, 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. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced. I touch the hypervisor instead of using virtio-serial, because 1. it is simple 2. the virtio-serial is an optional device, and the guest may not have such device. Changes from v2 to v3: 1. correct spelling Changes from v1 to v2: 1. split up host and guest-side changes 2. introduce new request flag to avoid changing return values. I see no Documentation/ changes. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/08/2012 07:13 PM, Avi Kivity Wrote: On 03/08/2012 09:57 AM, 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. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced. I touch the hypervisor instead of using virtio-serial, because 1. it is simple 2. the virtio-serial is an optional device, and the guest may not have such device. Changes from v2 to v3: 1. correct spelling Changes from v1 to v2: 1. split up host and guest-side changes 2. introduce new request flag to avoid changing return values. I see no Documentation/ changes. What shoude be writen into Documentation/? I read the documents under Documentation/virtual/kvm, not all KVM_EXIT_* are writen in api.txt. In this patch set, I introduce a new exit_reason: KVM_EXIT_GUEST_PANICKED, but I donot know where I should write. Thanks Wen Congyang -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
