[Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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.

[Qemu-devel] [PATCH 1/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

The implementation is the same as xen:
register panic notifier, and call hypercall when the guest
is paniced.

Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
---
 arch/x86/kernel/kvm.c    |   12 ++++++++++++
 include/linux/kvm_para.h |    1 +
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index f0c6fd6..7f9afc5 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -331,6 +331,17 @@ static struct notifier_block kvm_pv_reboot_nb = {
 	.notifier_call = kvm_pv_reboot_notify,
 };
 
+static int
+kvm_pv_panic_notify(struct notifier_block *nb, unsigned long code, void *unused)
+{
+	kvm_hypercall0(KVM_HC_GUEST_PANICKED);
+	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;
@@ -417,6 +428,7 @@ void __init kvm_guest_init(void)
 
 	paravirt_ops_setup();
 	register_reboot_notifier(&kvm_pv_reboot_nb);
+	atomic_notifier_chain_register(&panic_notifier_list, &kvm_pv_panic_nb);
 	for (i = 0; i < KVM_TASK_SLEEP_HASHSIZE; i++)
 		spin_lock_init(&async_pf_sleepers[i].lock);
 	if (kvm_para_has_feature(KVM_FEATURE_ASYNC_PF))
diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
index ff476dd..d030a22 100644
--- a/include/linux/kvm_para.h
+++ b/include/linux/kvm_para.h
@@ -19,6 +19,7 @@
 #define KVM_HC_MMU_OP			2
 #define KVM_HC_FEATURES			3
 #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
+#define KVM_HC_GUEST_PANICKED		5
 
 /*
  * hypercalls use architecture specific
-- 
1.7.1

[Qemu-devel] [PATCH 2/2 v3] kvm: set exit_reason to KVM_EXIT_GUEST_PANICKED when guest panicked

[Wen Congyang]

This patch introduces new request bit KVM_REQ_GUEST_PANICEKD.
If this bit is set, set vcpu's exit_reason to KVM_EXIT_GUEST_PANICKED.
And then the user space can know the guest panicked.

Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
---
 arch/x86/kvm/x86.c       |   11 +++++++++++
 include/linux/kvm.h      |    1 +
 include/linux/kvm_host.h |    1 +
 3 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c9d99e5..978e398 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5013,6 +5013,10 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
 	case KVM_HC_VAPIC_POLL_IRQ:
 		ret = 0;
 		break;
+	case KVM_HC_GUEST_PANICKED:
+		ret = 0;
+		kvm_make_request(KVM_REQ_GUEST_PANICKED, vcpu);
+		break;
 	default:
 		ret = -KVM_ENOSYS;
 		break;
@@ -5228,6 +5232,13 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
 			r = 0;
 			goto out;
 		}
+
+		if (kvm_check_request(KVM_REQ_GUEST_PANICKED, vcpu)) {
+			vcpu->run->exit_reason = KVM_EXIT_GUEST_PANICKED;
+			r = 0;
+			goto out;
+		}
+
 		if (kvm_check_request(KVM_REQ_DEACTIVATE_FPU, vcpu)) {
 			vcpu->fpu_active = 0;
 			kvm_x86_ops->fpu_deactivate(vcpu);
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index acbe429..a46052e 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -163,6 +163,7 @@ struct kvm_pit_config {
 #define KVM_EXIT_OSI              18
 #define KVM_EXIT_PAPR_HCALL	  19
 #define KVM_EXIT_S390_UCONTROL	  20
+#define KVM_EXIT_GUEST_PANICKED	  21
 
 /* For KVM_EXIT_INTERNAL_ERROR */
 #define KVM_INTERNAL_ERROR_EMULATION 1
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 355e445..026bbe5 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -54,6 +54,7 @@
 #define KVM_REQ_IMMEDIATE_EXIT    15
 #define KVM_REQ_PMU               16
 #define KVM_REQ_PMI               17
+#define KVM_REQ_GUEST_PANICKED     18
 
 #define KVM_USERSPACE_IRQ_SOURCE_ID	0
 
-- 
1.7.1

[Qemu-devel] [PATCH 1/2 v3] update linux-headers

[Wen Congyang]

Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
---
 linux-headers/asm-s390/kvm.h   |    2 ++
 linux-headers/linux/kvm.h      |    7 +++++++
 linux-headers/linux/kvm_para.h |    1 +
 3 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/linux-headers/asm-s390/kvm.h b/linux-headers/asm-s390/kvm.h
index 9acbde4..9607667 100644
--- a/linux-headers/asm-s390/kvm.h
+++ b/linux-headers/asm-s390/kvm.h
@@ -44,10 +44,12 @@ struct kvm_guest_debug_arch {
 #define KVM_SYNC_PREFIX (1UL << 0)
 #define KVM_SYNC_GPRS   (1UL << 1)
 #define KVM_SYNC_ACRS   (1UL << 2)
+#define KVM_SYNC_CRS    (1UL << 3)
 /* definition of registers in kvm_run */
 struct kvm_sync_regs {
 	__u64 prefix;	/* prefix register */
 	__u64 gprs[16];	/* general purpose registers */
 	__u32 acrs[16];	/* access registers */
+	__u64 crs[16];	/* control registers */
 };
 #endif
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index f6b5343..aa1c65e 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -163,6 +163,7 @@ struct kvm_pit_config {
 #define KVM_EXIT_OSI              18
 #define KVM_EXIT_PAPR_HCALL	  19
 #define KVM_EXIT_S390_UCONTROL	  20
+#define KVM_EXIT_GUEST_PANICKED	  21
 
 /* For KVM_EXIT_INTERNAL_ERROR */
 #define KVM_INTERNAL_ERROR_EMULATION 1
@@ -588,6 +589,7 @@ struct kvm_ppc_pvinfo {
 #define KVM_CAP_TSC_DEADLINE_TIMER 72
 #define KVM_CAP_S390_UCONTROL 73
 #define KVM_CAP_SYNC_REGS 74
+#define KVM_CAP_PCI_2_3 75
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
@@ -784,6 +786,9 @@ struct kvm_s390_ucas_mapping {
 /* Available with KVM_CAP_TSC_CONTROL */
 #define KVM_SET_TSC_KHZ           _IO(KVMIO,  0xa2)
 #define KVM_GET_TSC_KHZ           _IO(KVMIO,  0xa3)
+/* Available with KVM_CAP_PCI_2_3 */
+#define KVM_ASSIGN_SET_INTX_MASK  _IOW(KVMIO,  0xa4, \
+				       struct kvm_assigned_pci_dev)
 
 /*
  * ioctls for vcpu fds
@@ -857,6 +862,8 @@ struct kvm_s390_ucas_mapping {
 #define KVM_SET_ONE_REG		  _IOW(KVMIO,  0xac, struct kvm_one_reg)
 
 #define KVM_DEV_ASSIGN_ENABLE_IOMMU	(1 << 0)
+#define KVM_DEV_ASSIGN_PCI_2_3		(1 << 1)
+#define KVM_DEV_ASSIGN_MASK_INTX	(1 << 2)
 
 struct kvm_assigned_pci_dev {
 	__u32 assigned_dev_id;
diff --git a/linux-headers/linux/kvm_para.h b/linux-headers/linux/kvm_para.h
index 7bdcf93..9be20ee 100644
--- a/linux-headers/linux/kvm_para.h
+++ b/linux-headers/linux/kvm_para.h
@@ -19,6 +19,7 @@
 #define KVM_HC_MMU_OP			2
 #define KVM_HC_FEATURES			3
 #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
+#define KVM_HC_GUEST_PANICKED		5
 
 /*
  * hypercalls use architecture specific
-- 
1.7.1

[Qemu-devel] [PATCH 2/2 v3] deal with guest panicked event

[Wen Congyang]

When the host knows the guest is panicked, it will set
exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive
this exit_reason, we can send a event to tell management
application that the guest is panicked and set the guest
status to RUN_STATE_PANICKED.

Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
---
 kvm-all.c        |    4 ++++
 monitor.c        |    3 +++
 monitor.h        |    1 +
 qapi-schema.json |    2 +-
 qmp.c            |    3 ++-
 vl.c             |    1 +
 6 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index 77eadf6..01062af 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1290,6 +1290,10 @@ int kvm_cpu_exec(CPUState *env)
                     (uint64_t)run->hw.hardware_exit_reason);
             ret = -1;
             break;
+        case KVM_EXIT_GUEST_PANICKED:
+            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
+            vm_stop(RUN_STATE_PANICKED);
+            break;
         case KVM_EXIT_INTERNAL_ERROR:
             ret = kvm_handle_internal_error(env, run);
             break;
diff --git a/monitor.c b/monitor.c
index cbdfbad..a0ad0a9 100644
--- a/monitor.c
+++ b/monitor.c
@@ -494,6 +494,9 @@ void monitor_protocol_event(MonitorEvent event, QObject *data)
         case QEVENT_WAKEUP:
             event_name = "WAKEUP";
             break;
+        case QEVENT_GUEST_PANICKED:
+            event_name = "GUEST_PANICKED";
+            break;
         default:
             abort();
             break;
diff --git a/monitor.h b/monitor.h
index 0d49800..94e8a3c 100644
--- a/monitor.h
+++ b/monitor.h
@@ -41,6 +41,7 @@ typedef enum MonitorEvent {
     QEVENT_DEVICE_TRAY_MOVED,
     QEVENT_SUSPEND,
     QEVENT_WAKEUP,
+    QEVENT_GUEST_PANICKED,
     QEVENT_MAX,
 } MonitorEvent;
 
diff --git a/qapi-schema.json b/qapi-schema.json
index 5f293c4..4f1ae20 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -121,7 +121,7 @@
 { 'enum': 'RunState',
   'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
             'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
-            'running', 'save-vm', 'shutdown', 'watchdog' ] }
+            'running', 'save-vm', 'shutdown', 'watchdog', 'panicked' ] }
 
 ##
 # @StatusInfo:
diff --git a/qmp.c b/qmp.c
index a182b51..e535969 100644
--- a/qmp.c
+++ b/qmp.c
@@ -148,7 +148,8 @@ void qmp_cont(Error **errp)
         error_set(errp, QERR_MIGRATION_EXPECTED);
         return;
     } else if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
-               runstate_check(RUN_STATE_SHUTDOWN)) {
+               runstate_check(RUN_STATE_SHUTDOWN) ||
+               runstate_check(RUN_STATE_PANICKED)) {
         error_set(errp, QERR_RESET_REQUIRED);
         return;
     }
diff --git a/vl.c b/vl.c
index 97ab2b9..65390fa 100644
--- a/vl.c
+++ b/vl.c
@@ -359,6 +359,7 @@ static const RunStateTransition runstate_transitions_def[] = {
     { RUN_STATE_RUNNING, RUN_STATE_SAVE_VM },
     { RUN_STATE_RUNNING, RUN_STATE_SHUTDOWN },
     { RUN_STATE_RUNNING, RUN_STATE_WATCHDOG },
+    { RUN_STATE_RUNNING, RUN_STATE_PANICKED },
 
     { RUN_STATE_SAVE_VM, RUN_STATE_RUNNING },
 
-- 
1.7.1

Re: [Qemu-devel] [PATCH 2/2 v3] deal with guest panicked event

[Jan Kiszka]

On 2012-03-08 09:07, Wen Congyang wrote:
> When the host knows the guest is panicked, it will set
> exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive
> this exit_reason, we can send a event to tell management
> application that the guest is panicked and set the guest
> status to RUN_STATE_PANICKED.
> 
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> ---
>  kvm-all.c        |    4 ++++
>  monitor.c        |    3 +++
>  monitor.h        |    1 +
>  qapi-schema.json |    2 +-
>  qmp.c            |    3 ++-
>  vl.c             |    1 +
>  6 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/kvm-all.c b/kvm-all.c
> index 77eadf6..01062af 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -1290,6 +1290,10 @@ int kvm_cpu_exec(CPUState *env)
>                      (uint64_t)run->hw.hardware_exit_reason);
>              ret = -1;
>              break;
> +        case KVM_EXIT_GUEST_PANICKED:
> +            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
> +            vm_stop(RUN_STATE_PANICKED);
> +            break;

You're still lacking "ret = -1;".

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH 2/2 v3] deal with guest panicked event

[Wen Congyang]

At 03/08/2012 06:08 PM, Jan Kiszka Wrote:
> On 2012-03-08 09:07, Wen Congyang wrote:
>> When the host knows the guest is panicked, it will set
>> exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive
>> this exit_reason, we can send a event to tell management
>> application that the guest is panicked and set the guest
>> status to RUN_STATE_PANICKED.
>>
>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>> ---
>>  kvm-all.c        |    4 ++++
>>  monitor.c        |    3 +++
>>  monitor.h        |    1 +
>>  qapi-schema.json |    2 +-
>>  qmp.c            |    3 ++-
>>  vl.c             |    1 +
>>  6 files changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/kvm-all.c b/kvm-all.c
>> index 77eadf6..01062af 100644
>> --- a/kvm-all.c
>> +++ b/kvm-all.c
>> @@ -1290,6 +1290,10 @@ int kvm_cpu_exec(CPUState *env)
>>                      (uint64_t)run->hw.hardware_exit_reason);
>>              ret = -1;
>>              break;
>> +        case KVM_EXIT_GUEST_PANICKED:
>> +            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
>> +            vm_stop(RUN_STATE_PANICKED);
>> +            break;
> 
> You're still lacking "ret = -1;".

Sorry, I forgot it...

Thanks
Wen Congyang

> 
> Jan
> 

[Qemu-devel] [RESEND][PATCH 2/2 v3] deal with guest panicked event

[Wen Congyang]

When the host knows the guest is panicked, it will set
exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive
this exit_reason, we can send a event to tell management
application that the guest is panicked and set the guest
status to RUN_STATE_PANICKED.

Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
---
 kvm-all.c        |    5 +++++
 monitor.c        |    3 +++
 monitor.h        |    1 +
 qapi-schema.json |    2 +-
 qmp.c            |    3 ++-
 vl.c             |    1 +
 6 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/kvm-all.c b/kvm-all.c
index 77eadf6..b3c9a83 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1290,6 +1290,11 @@ int kvm_cpu_exec(CPUState *env)
                     (uint64_t)run->hw.hardware_exit_reason);
             ret = -1;
             break;
+        case KVM_EXIT_GUEST_PANICKED:
+            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
+            vm_stop(RUN_STATE_PANICKED);
+            ret = -1;
+            break;
         case KVM_EXIT_INTERNAL_ERROR:
             ret = kvm_handle_internal_error(env, run);
             break;
diff --git a/monitor.c b/monitor.c
index cbdfbad..a0ad0a9 100644
--- a/monitor.c
+++ b/monitor.c
@@ -494,6 +494,9 @@ void monitor_protocol_event(MonitorEvent event, QObject *data)
         case QEVENT_WAKEUP:
             event_name = "WAKEUP";
             break;
+        case QEVENT_GUEST_PANICKED:
+            event_name = "GUEST_PANICKED";
+            break;
         default:
             abort();
             break;
diff --git a/monitor.h b/monitor.h
index 0d49800..94e8a3c 100644
--- a/monitor.h
+++ b/monitor.h
@@ -41,6 +41,7 @@ typedef enum MonitorEvent {
     QEVENT_DEVICE_TRAY_MOVED,
     QEVENT_SUSPEND,
     QEVENT_WAKEUP,
+    QEVENT_GUEST_PANICKED,
     QEVENT_MAX,
 } MonitorEvent;
 
diff --git a/qapi-schema.json b/qapi-schema.json
index 5f293c4..4f1ae20 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -121,7 +121,7 @@
 { 'enum': 'RunState',
   'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
             'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
-            'running', 'save-vm', 'shutdown', 'watchdog' ] }
+            'running', 'save-vm', 'shutdown', 'watchdog', 'panicked' ] }
 
 ##
 # @StatusInfo:
diff --git a/qmp.c b/qmp.c
index a182b51..e535969 100644
--- a/qmp.c
+++ b/qmp.c
@@ -148,7 +148,8 @@ void qmp_cont(Error **errp)
         error_set(errp, QERR_MIGRATION_EXPECTED);
         return;
     } else if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
-               runstate_check(RUN_STATE_SHUTDOWN)) {
+               runstate_check(RUN_STATE_SHUTDOWN) ||
+               runstate_check(RUN_STATE_PANICKED)) {
         error_set(errp, QERR_RESET_REQUIRED);
         return;
     }
diff --git a/vl.c b/vl.c
index 97ab2b9..65390fa 100644
--- a/vl.c
+++ b/vl.c
@@ -359,6 +359,7 @@ static const RunStateTransition runstate_transitions_def[] = {
     { RUN_STATE_RUNNING, RUN_STATE_SAVE_VM },
     { RUN_STATE_RUNNING, RUN_STATE_SHUTDOWN },
     { RUN_STATE_RUNNING, RUN_STATE_WATCHDOG },
+    { RUN_STATE_RUNNING, RUN_STATE_PANICKED },
 
     { RUN_STATE_SAVE_VM, RUN_STATE_RUNNING },
 
-- 
1.7.1

Re: [Qemu-devel] [RESEND][PATCH 2/2 v3] deal with guest panicked event

[Avi Kivity]

On 03/08/2012 12:15 PM, Wen Congyang wrote:
> When the host knows the guest is panicked, it will set
> exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive
> this exit_reason, we can send a event to tell management
> application that the guest is panicked and set the guest
> status to RUN_STATE_PANICKED.
>
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> ---
>  kvm-all.c        |    5 +++++
>  monitor.c        |    3 +++
>  monitor.h        |    1 +
>  qapi-schema.json |    2 +-
>  qmp.c            |    3 ++-
>  vl.c             |    1 +
>  6 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/kvm-all.c b/kvm-all.c
> index 77eadf6..b3c9a83 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -1290,6 +1290,11 @@ int kvm_cpu_exec(CPUState *env)
>                      (uint64_t)run->hw.hardware_exit_reason);
>              ret = -1;
>              break;
> +        case KVM_EXIT_GUEST_PANICKED:
> +            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
> +            vm_stop(RUN_STATE_PANICKED);
> +            ret = -1;
> +            break;
>

If the management application is not aware of this event, then it will
never resume the guest, so it will appear hung.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [RESEND][PATCH 2/2 v3] deal with guest panicked event

[Daniel P. Berrange]

On Thu, Mar 08, 2012 at 01:28:56PM +0200, Avi Kivity wrote:
> On 03/08/2012 12:15 PM, Wen Congyang wrote:
> > When the host knows the guest is panicked, it will set
> > exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive
> > this exit_reason, we can send a event to tell management
> > application that the guest is panicked and set the guest
> > status to RUN_STATE_PANICKED.
> >
> > Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> > ---
> >  kvm-all.c        |    5 +++++
> >  monitor.c        |    3 +++
> >  monitor.h        |    1 +
> >  qapi-schema.json |    2 +-
> >  qmp.c            |    3 ++-
> >  vl.c             |    1 +
> >  6 files changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/kvm-all.c b/kvm-all.c
> > index 77eadf6..b3c9a83 100644
> > --- a/kvm-all.c
> > +++ b/kvm-all.c
> > @@ -1290,6 +1290,11 @@ int kvm_cpu_exec(CPUState *env)
> >                      (uint64_t)run->hw.hardware_exit_reason);
> >              ret = -1;
> >              break;
> > +        case KVM_EXIT_GUEST_PANICKED:
> > +            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
> > +            vm_stop(RUN_STATE_PANICKED);
> > +            ret = -1;
> > +            break;
> >
> 
> If the management application is not aware of this event, then it will
> never resume the guest, so it will appear hung.

Even if the mgmt app doesn't know about the QEVENT_GUEST_PANICKED, it should
still see a QEVENT_STOP event emitted by vm_stop() surely ? So it will
know the guest CPUs have been stopped, even if it isn't aware of the
reason why, which seems fine to me.

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 :|

Re: [Qemu-devel] [RESEND][PATCH 2/2 v3] deal with guest panicked event

[Avi Kivity]

On 03/08/2012 01:36 PM, Daniel P. Berrange wrote:
> On Thu, Mar 08, 2012 at 01:28:56PM +0200, Avi Kivity wrote:
> > On 03/08/2012 12:15 PM, Wen Congyang wrote:
> > > When the host knows the guest is panicked, it will set
> > > exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive
> > > this exit_reason, we can send a event to tell management
> > > application that the guest is panicked and set the guest
> > > status to RUN_STATE_PANICKED.
> > >
> > > Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> > > ---
> > >  kvm-all.c        |    5 +++++
> > >  monitor.c        |    3 +++
> > >  monitor.h        |    1 +
> > >  qapi-schema.json |    2 +-
> > >  qmp.c            |    3 ++-
> > >  vl.c             |    1 +
> > >  6 files changed, 13 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/kvm-all.c b/kvm-all.c
> > > index 77eadf6..b3c9a83 100644
> > > --- a/kvm-all.c
> > > +++ b/kvm-all.c
> > > @@ -1290,6 +1290,11 @@ int kvm_cpu_exec(CPUState *env)
> > >                      (uint64_t)run->hw.hardware_exit_reason);
> > >              ret = -1;
> > >              break;
> > > +        case KVM_EXIT_GUEST_PANICKED:
> > > +            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
> > > +            vm_stop(RUN_STATE_PANICKED);
> > > +            ret = -1;
> > > +            break;
> > >
> > 
> > If the management application is not aware of this event, then it will
> > never resume the guest, so it will appear hung.
>
> Even if the mgmt app doesn't know about the QEVENT_GUEST_PANICKED, it should
> still see a QEVENT_STOP event emitted by vm_stop() surely ? So it will
> know the guest CPUs have been stopped, even if it isn't aware of the
> reason why, which seems fine to me.

No.  The guest is stopped, and there's no reason to suppose that the
management app will restart it.  Behaviour has changed.

Suppose the guest has reboot_on_panic set; now the behaviour change is
even more visible - service will stop completely instead of being
interrupted for a bit while the guest reboots.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [RESEND][PATCH 2/2 v3] deal with guest panicked event

[Daniel P. Berrange]

On Thu, Mar 08, 2012 at 01:52:45PM +0200, Avi Kivity wrote:
> On 03/08/2012 01:36 PM, Daniel P. Berrange wrote:
> > On Thu, Mar 08, 2012 at 01:28:56PM +0200, Avi Kivity wrote:
> > > On 03/08/2012 12:15 PM, Wen Congyang wrote:
> > > > When the host knows the guest is panicked, it will set
> > > > exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive
> > > > this exit_reason, we can send a event to tell management
> > > > application that the guest is panicked and set the guest
> > > > status to RUN_STATE_PANICKED.
> > > >
> > > > Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> > > > ---
> > > >  kvm-all.c        |    5 +++++
> > > >  monitor.c        |    3 +++
> > > >  monitor.h        |    1 +
> > > >  qapi-schema.json |    2 +-
> > > >  qmp.c            |    3 ++-
> > > >  vl.c             |    1 +
> > > >  6 files changed, 13 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/kvm-all.c b/kvm-all.c
> > > > index 77eadf6..b3c9a83 100644
> > > > --- a/kvm-all.c
> > > > +++ b/kvm-all.c
> > > > @@ -1290,6 +1290,11 @@ int kvm_cpu_exec(CPUState *env)
> > > >                      (uint64_t)run->hw.hardware_exit_reason);
> > > >              ret = -1;
> > > >              break;
> > > > +        case KVM_EXIT_GUEST_PANICKED:
> > > > +            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
> > > > +            vm_stop(RUN_STATE_PANICKED);
> > > > +            ret = -1;
> > > > +            break;
> > > >
> > > 
> > > If the management application is not aware of this event, then it will
> > > never resume the guest, so it will appear hung.
> >
> > Even if the mgmt app doesn't know about the QEVENT_GUEST_PANICKED, it should
> > still see a QEVENT_STOP event emitted by vm_stop() surely ? So it will
> > know the guest CPUs have been stopped, even if it isn't aware of the
> > reason why, which seems fine to me.
> 
> No.  The guest is stopped, and there's no reason to suppose that the
> management app will restart it.  Behaviour has changed.
> 
> Suppose the guest has reboot_on_panic set; now the behaviour change is
> even more visible - service will stop completely instead of being
> interrupted for a bit while the guest reboots.

Hmm, so this calls for a new command line argument to control behaviour,
similar to what we do for disk werror, eg something like

  --onpanic "report|pause|stop|..."

where

 report - emit QEVENT_GUEST_PANICKED only
 pause  - emit QEVENT_GUEST_PANICKED and pause VM
 stop   - emit QEVENT_GUEST_PANICKED and quit VM
 stop   - emit QEVENT_GUEST_PANICKED and quit VM

This would map fairly well into libvirt, where we already have config
parameters for controlling what todo with a guest when it panics.

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 :|

Re: [Qemu-devel] [RESEND][PATCH 2/2 v3] deal with guest panicked event

[Marcelo Tosatti]

On Thu, Mar 08, 2012 at 11:56:56AM +0000, Daniel P. Berrange wrote:
> On Thu, Mar 08, 2012 at 01:52:45PM +0200, Avi Kivity wrote:
> > On 03/08/2012 01:36 PM, Daniel P. Berrange wrote:
> > > On Thu, Mar 08, 2012 at 01:28:56PM +0200, Avi Kivity wrote:
> > > > On 03/08/2012 12:15 PM, Wen Congyang wrote:
> > > > > When the host knows the guest is panicked, it will set
> > > > > exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive
> > > > > this exit_reason, we can send a event to tell management
> > > > > application that the guest is panicked and set the guest
> > > > > status to RUN_STATE_PANICKED.
> > > > >
> > > > > Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> > > > > ---
> > > > >  kvm-all.c        |    5 +++++
> > > > >  monitor.c        |    3 +++
> > > > >  monitor.h        |    1 +
> > > > >  qapi-schema.json |    2 +-
> > > > >  qmp.c            |    3 ++-
> > > > >  vl.c             |    1 +
> > > > >  6 files changed, 13 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/kvm-all.c b/kvm-all.c
> > > > > index 77eadf6..b3c9a83 100644
> > > > > --- a/kvm-all.c
> > > > > +++ b/kvm-all.c
> > > > > @@ -1290,6 +1290,11 @@ int kvm_cpu_exec(CPUState *env)
> > > > >                      (uint64_t)run->hw.hardware_exit_reason);
> > > > >              ret = -1;
> > > > >              break;
> > > > > +        case KVM_EXIT_GUEST_PANICKED:
> > > > > +            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
> > > > > +            vm_stop(RUN_STATE_PANICKED);
> > > > > +            ret = -1;
> > > > > +            break;
> > > > >
> > > > 
> > > > If the management application is not aware of this event, then it will
> > > > never resume the guest, so it will appear hung.
> > >
> > > Even if the mgmt app doesn't know about the QEVENT_GUEST_PANICKED, it should
> > > still see a QEVENT_STOP event emitted by vm_stop() surely ? So it will
> > > know the guest CPUs have been stopped, even if it isn't aware of the
> > > reason why, which seems fine to me.
> > 
> > No.  The guest is stopped, and there's no reason to suppose that the
> > management app will restart it.  Behaviour has changed.
> > 
> > Suppose the guest has reboot_on_panic set; now the behaviour change is
> > even more visible - service will stop completely instead of being
> > interrupted for a bit while the guest reboots.
> 
> Hmm, so this calls for a new command line argument to control behaviour,
> similar to what we do for disk werror, eg something like
> 
>   --onpanic "report|pause|stop|..."
> 
> where
> 
>  report - emit QEVENT_GUEST_PANICKED only

Should be the default.

>  pause  - emit QEVENT_GUEST_PANICKED and pause VM
>  stop   - emit QEVENT_GUEST_PANICKED and quit VM

"quit" is a better name than "stop".

> This would map fairly well into libvirt, where we already have config
> parameters for controlling what todo with a guest when it panics.
> 
> Regards,
> Daniel

Re: [Qemu-devel] [RESEND][PATCH 2/2 v3] deal with guest panicked event

[Anthony Liguori]

On 03/09/2012 04:22 PM, Marcelo Tosatti wrote:
> On Thu, Mar 08, 2012 at 11:56:56AM +0000, Daniel P. Berrange wrote:
>> On Thu, Mar 08, 2012 at 01:52:45PM +0200, Avi Kivity wrote:
>>> On 03/08/2012 01:36 PM, Daniel P. Berrange wrote:
>>>> On Thu, Mar 08, 2012 at 01:28:56PM +0200, Avi Kivity wrote:
>>>>> On 03/08/2012 12:15 PM, Wen Congyang wrote:
>>>>>> When the host knows the guest is panicked, it will set
>>>>>> exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive
>>>>>> this exit_reason, we can send a event to tell management
>>>>>> application that the guest is panicked and set the guest
>>>>>> status to RUN_STATE_PANICKED.
>>>>>>
>>>>>> Signed-off-by: Wen Congyang<wency@cn.fujitsu.com>
>>>>>> ---
>>>>>>   kvm-all.c        |    5 +++++
>>>>>>   monitor.c        |    3 +++
>>>>>>   monitor.h        |    1 +
>>>>>>   qapi-schema.json |    2 +-
>>>>>>   qmp.c            |    3 ++-
>>>>>>   vl.c             |    1 +
>>>>>>   6 files changed, 13 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/kvm-all.c b/kvm-all.c
>>>>>> index 77eadf6..b3c9a83 100644
>>>>>> --- a/kvm-all.c
>>>>>> +++ b/kvm-all.c
>>>>>> @@ -1290,6 +1290,11 @@ int kvm_cpu_exec(CPUState *env)
>>>>>>                       (uint64_t)run->hw.hardware_exit_reason);
>>>>>>               ret = -1;
>>>>>>               break;
>>>>>> +        case KVM_EXIT_GUEST_PANICKED:
>>>>>> +            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
>>>>>> +            vm_stop(RUN_STATE_PANICKED);
>>>>>> +            ret = -1;
>>>>>> +            break;
>>>>>>
>>>>>
>>>>> If the management application is not aware of this event, then it will
>>>>> never resume the guest, so it will appear hung.
>>>>
>>>> Even if the mgmt app doesn't know about the QEVENT_GUEST_PANICKED, it should
>>>> still see a QEVENT_STOP event emitted by vm_stop() surely ? So it will
>>>> know the guest CPUs have been stopped, even if it isn't aware of the
>>>> reason why, which seems fine to me.
>>>
>>> No.  The guest is stopped, and there's no reason to suppose that the
>>> management app will restart it.  Behaviour has changed.
>>>
>>> Suppose the guest has reboot_on_panic set; now the behaviour change is
>>> even more visible - service will stop completely instead of being
>>> interrupted for a bit while the guest reboots.
>>
>> Hmm, so this calls for a new command line argument to control behaviour,
>> similar to what we do for disk werror, eg something like
>>
>>    --onpanic "report|pause|stop|..."
>>
>> where
>>
>>   report - emit QEVENT_GUEST_PANICKED only
>
> Should be the default.

Should we just have a mechanism to stop the guest on certain types of QMP 
events?  For instance:

-stop-on guest-panicked,block-ioerror

Likewise, we could have a:

-quit-on guest-panicked.

In the very least, we should make what we use for rerror,werror an enumeration 
that's shared here.

Regards,

Anthony Liguori

>
>>   pause  - emit QEVENT_GUEST_PANICKED and pause VM
>>   stop   - emit QEVENT_GUEST_PANICKED and quit VM
>
> "quit" is a better name than "stop".
>
>> This would map fairly well into libvirt, where we already have config
>> parameters for controlling what todo with a guest when it panics.
>>
>> Regards,
>> Daniel
>
>

Re: [Qemu-devel] [RESEND][PATCH 2/2 v3] deal with guest panicked event

[Wen Congyang]

At 03/08/2012 07:56 PM, Daniel P. Berrange Wrote:
> On Thu, Mar 08, 2012 at 01:52:45PM +0200, Avi Kivity wrote:
>> On 03/08/2012 01:36 PM, Daniel P. Berrange wrote:
>>> On Thu, Mar 08, 2012 at 01:28:56PM +0200, Avi Kivity wrote:
>>>> On 03/08/2012 12:15 PM, Wen Congyang wrote:
>>>>> When the host knows the guest is panicked, it will set
>>>>> exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive
>>>>> this exit_reason, we can send a event to tell management
>>>>> application that the guest is panicked and set the guest
>>>>> status to RUN_STATE_PANICKED.
>>>>>
>>>>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>>>>> ---
>>>>>  kvm-all.c        |    5 +++++
>>>>>  monitor.c        |    3 +++
>>>>>  monitor.h        |    1 +
>>>>>  qapi-schema.json |    2 +-
>>>>>  qmp.c            |    3 ++-
>>>>>  vl.c             |    1 +
>>>>>  6 files changed, 13 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/kvm-all.c b/kvm-all.c
>>>>> index 77eadf6..b3c9a83 100644
>>>>> --- a/kvm-all.c
>>>>> +++ b/kvm-all.c
>>>>> @@ -1290,6 +1290,11 @@ int kvm_cpu_exec(CPUState *env)
>>>>>                      (uint64_t)run->hw.hardware_exit_reason);
>>>>>              ret = -1;
>>>>>              break;
>>>>> +        case KVM_EXIT_GUEST_PANICKED:
>>>>> +            monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL);
>>>>> +            vm_stop(RUN_STATE_PANICKED);
>>>>> +            ret = -1;
>>>>> +            break;
>>>>>
>>>>
>>>> If the management application is not aware of this event, then it will
>>>> never resume the guest, so it will appear hung.
>>>
>>> Even if the mgmt app doesn't know about the QEVENT_GUEST_PANICKED, it should
>>> still see a QEVENT_STOP event emitted by vm_stop() surely ? So it will
>>> know the guest CPUs have been stopped, even if it isn't aware of the
>>> reason why, which seems fine to me.
>>
>> No.  The guest is stopped, and there's no reason to suppose that the
>> management app will restart it.  Behaviour has changed.
>>
>> Suppose the guest has reboot_on_panic set; now the behaviour change is
>> even more visible - service will stop completely instead of being
>> interrupted for a bit while the guest reboots.
> 
> Hmm, so this calls for a new command line argument to control behaviour,
> similar to what we do for disk werror, eg something like
> 
>   --onpanic "report|pause|stop|..."
> 
> where
> 
>  report - emit QEVENT_GUEST_PANICKED only

If the guest is panicked when libvirt is stopped, and we only emit a event,
we cannot know the guest is panicked when libvirt starts.

So I add a new RunState to solve this problem. If the guest is stopped when
it is panicked, it will change the behaviour. So I think the new RunState
should be a running state.

Thanks
Wen Congyang

>  pause  - emit QEVENT_GUEST_PANICKED and pause VM
>  stop   - emit QEVENT_GUEST_PANICKED and quit VM
>  stop   - emit QEVENT_GUEST_PANICKED and quit VM
> 
> This would map fairly well into libvirt, where we already have config
> parameters for controlling what todo with a guest when it panics.
> 
> Regards,
> Daniel

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Avi Kivity]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Avi Kivity]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Avi Kivity]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Daniel P. Berrange]

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 :|

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Avi Kivity]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Avi Kivity]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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

> 

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Avi Kivity]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Avi Kivity]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Gleb Natapov]

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.

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Avi Kivity]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Avi Kivity]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Avi Kivity]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Gleb Natapov]

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.

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Avi Kivity]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Gleb Natapov]

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.

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Eric Northup]

[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]

On Wed, Mar 14, 2012 at 6:25 AM, Gleb Natapov <gleb@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.

[-- Attachment #2: Type: text/html, Size: 2720 bytes --]

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

At 03/15/2012 02:46 AM, Eric Northup Wrote:
> On Wed, Mar 14, 2012 at 6:25 AM, Gleb Natapov <gleb@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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Gleb Natapov]

On Wed, Mar 14, 2012 at 11:46:08AM -0700, Eric Northup wrote:
> On Wed, Mar 14, 2012 at 6:25 AM, Gleb Natapov <gleb@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.

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Jan Kiszka]

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 <gleb@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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Avi Kivity]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

At 03/15/2012 07:46 PM, Avi Kivity Wrote:
> 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.
> 

I prefer this:
host <-> guest kernel: use hypercall

host <-> guest userspace: use virtio-serial(or other way that not modify kernel)

Thanks
Wen Congyang

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Anthony Liguori]

On 03/15/2012 06:46 AM, Avi Kivity wrote:
> 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.

Just declare that outl 0x505 is a megaultracall and s/vmcall/outb/g and call it 
a day.

The performance difference between vmcall and outl is so tiny compared to the 
cost of dropping to userspace that it really doesn't matter which instruction is 
used.

Regards,

Anthony Liguori

>

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

At 03/22/2012 03:12 AM, Anthony Liguori Wrote:
> On 03/15/2012 06:46 AM, Avi Kivity wrote:
>> 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.
> 
> Just declare that outl 0x505 is a megaultracall and s/vmcall/outb/g and
> call it a day.

Why use 0x505? Is it a reserved port, and it will not be used by any device?

How can I get all reserved port?

Thanks
Wen Congyang

> 
> The performance difference between vmcall and outl is so tiny compared
> to the cost of dropping to userspace that it really doesn't matter which
> instruction is used.
> 
> Regards,
> 
> Anthony Liguori
> 
>>
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Eric Northup]

On Wed, Mar 14, 2012 at 6:25 AM, Gleb Natapov <gleb@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.

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Amit Shah]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Gleb Natapov]

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.

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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.
> 

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Gleb Natapov]

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.

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Avi Kivity]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Daniel P. Berrange]

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 :|

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Gleb Natapov]

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.

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Daniel P. Berrange]

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 :|

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Gleb Natapov]

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.

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Amit Shah]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Amit Shah]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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
> 

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Avi Kivity]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Amit Shah]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Gleb Natapov]

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.

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Daniel P. Berrange]

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 :|

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Anthony Liguori]

On 03/13/2012 05:47 AM, 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.

The problem is that virtio-serial sucks for something like this.

We have two options I think:

1) We could reserve a portion of the hypercall space to be deferred to userspace 
for stuff like this.

2) We could invent a new hypercall like facility that was less bloated than 
virtio-serial for stuff like this using MMIO/PIO.

Regards,

Anthony Liguori

>

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Gleb Natapov]

On Wed, Mar 21, 2012 at 02:04:34PM -0500, Anthony Liguori wrote:
> On 03/13/2012 05:47 AM, 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.
> 
> The problem is that virtio-serial sucks for something like this.
> 
How do we know if we haven't tried :)

> We have two options I think:
> 
> 1) We could reserve a portion of the hypercall space to be deferred
> to userspace for stuff like this.
> 
> 2) We could invent a new hypercall like facility that was less
> bloated than virtio-serial for stuff like this using MMIO/PIO.
> 
> Regards,
> 
> Anthony Liguori
> 
> >

--
			Gleb.

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Avi Kivity]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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 majordomo@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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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 majordomo@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Gleb Natapov]

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 majordomo@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.

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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 majordomo@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Gleb Natapov]

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 majordomo@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.

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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 majordomo@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.
> 

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Gleb Natapov]

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 majordomo@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.

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Corey Minyard]

> 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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Gleb Natapov]

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.

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Avi Kivity]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Daniel P. Berrange]

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 :|

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Avi Kivity]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Jan Kiszka]

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

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Anthony Liguori]

On 03/21/2012 11:25 AM, 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.

I think the use case here is pretty straight forward: if the guest finds itself 
in bad place, it wants to indicate that to the host.

We shouldn't rely on any device drivers or complex code.  It should be as close 
to a single instruction as possible that can run even if interrupts are disabled.

An out instruction fits this very well.  I think a simple protocol like:

inl PORT -> returns a magic number indicating the presence of qemucalls
inl PORT+1 -> returns a bitmap of supported features

outl PORT+1 -> data reg1
outl PORT+2 -> data reg2
outl PORT+N -> data regN

outl PORT -> qemucall of index value with arguments 1..N

Regards,

Anthony Liguori

>
> In fact the feature can be implemented 100% host side by searching for a
> panic string signature in the console logs.
>

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

At 03/22/2012 03:19 AM, Anthony Liguori Wrote:
> On 03/21/2012 11:25 AM, 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.
> 
> I think the use case here is pretty straight forward: if the guest finds
> itself in bad place, it wants to indicate that to the host.
> 
> We shouldn't rely on any device drivers or complex code.  It should be
> as close to a single instruction as possible that can run even if
> interrupts are disabled.
> 
> An out instruction fits this very well.  I think a simple protocol like:

This solution is more simple than using virtio-serial.

> 
> inl PORT -> returns a magic number indicating the presence of qemucalls

I donot understantd this instruction's purpose.

> inl PORT+1 -> returns a bitmap of supported features

Hmm, we can execute this instruction when guest starts. If the userspace
does not process panicked event, there is no need to notify it.

> 
> outl PORT+1 -> data reg1
> outl PORT+2 -> data reg2
> outl PORT+N -> data regN

We can get the register value from vmcs. So there is no need to tell
the register value to the host.

If we decide to avoid touching hypervisor, I agree with this solution.

Thanks
Wen Congyang
> 
> outl PORT -> qemucall of index value with arguments 1..N
> 
> Regards,
> 
> Anthony Liguori
> 
>>
>> In fact the feature can be implemented 100% host side by searching for a
>> panic string signature in the console logs.
>>
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Gleb Natapov]

On Thu, Mar 22, 2012 at 09:05:12AM +0800, Wen Congyang wrote:
> At 03/22/2012 03:19 AM, Anthony Liguori Wrote:
> > On 03/21/2012 11:25 AM, 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.
> > 
> > I think the use case here is pretty straight forward: if the guest finds
> > itself in bad place, it wants to indicate that to the host.
> > 
> > We shouldn't rely on any device drivers or complex code.  It should be
> > as close to a single instruction as possible that can run even if
> > interrupts are disabled.
> > 
> > An out instruction fits this very well.  I think a simple protocol like:
> 
> This solution is more simple than using virtio-serial.
> 
> > 
> > inl PORT -> returns a magic number indicating the presence of qemucalls
> 
> I donot understantd this instruction's purpose.
> 
> > inl PORT+1 -> returns a bitmap of supported features
> 
> Hmm, we can execute this instruction when guest starts. If the userspace
> does not process panicked event, there is no need to notify it.
> 
> > 
> > outl PORT+1 -> data reg1
> > outl PORT+2 -> data reg2
> > outl PORT+N -> data regN
> 
> We can get the register value from vmcs. So there is no need to tell
> the register value to the host.
> 
No device should examine register value. Ideally QEMU would read
registers only during migration.

> If we decide to avoid touching hypervisor, I agree with this solution.
> 
> Thanks
> Wen Congyang
> > 
> > outl PORT -> qemucall of index value with arguments 1..N
> > 
> > Regards,
> > 
> > Anthony Liguori
> > 
> >>
> >> In fact the feature can be implemented 100% host side by searching for a
> >> panic string signature in the console logs.
> >>
> > 
> > -- 
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 

--
			Gleb.

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

At 03/22/2012 03:31 PM, Gleb Natapov Wrote:
> On Thu, Mar 22, 2012 at 09:05:12AM +0800, Wen Congyang wrote:
>> At 03/22/2012 03:19 AM, Anthony Liguori Wrote:
>>> On 03/21/2012 11:25 AM, 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.
>>>
>>> I think the use case here is pretty straight forward: if the guest finds
>>> itself in bad place, it wants to indicate that to the host.
>>>
>>> We shouldn't rely on any device drivers or complex code.  It should be
>>> as close to a single instruction as possible that can run even if
>>> interrupts are disabled.
>>>
>>> An out instruction fits this very well.  I think a simple protocol like:
>>
>> This solution is more simple than using virtio-serial.
>>
>>>
>>> inl PORT -> returns a magic number indicating the presence of qemucalls
>>
>> I donot understantd this instruction's purpose.
>>
>>> inl PORT+1 -> returns a bitmap of supported features
>>
>> Hmm, we can execute this instruction when guest starts. If the userspace
>> does not process panicked event, there is no need to notify it.
>>
>>>
>>> outl PORT+1 -> data reg1
>>> outl PORT+2 -> data reg2
>>> outl PORT+N -> data regN
>>
>> We can get the register value from vmcs. So there is no need to tell
>> the register value to the host.
>>
> No device should examine register value. Ideally QEMU would read
> registers only during migration.

I mean: if the qemu(or other app) want to know the register value, it can
get it from vmcs. So there is no need to pass register value from guest
to host.

Another question: each outl will cause vmexit?

Thanks
Wen Congyang

> 
>> If we decide to avoid touching hypervisor, I agree with this solution.
>>
>> Thanks
>> Wen Congyang
>>>
>>> outl PORT -> qemucall of index value with arguments 1..N
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>
>>>>
>>>> In fact the feature can be implemented 100% host side by searching for a
>>>> panic string signature in the console logs.
>>>>
>>>
>>> -- 
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>
> 
> --
> 			Gleb.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Gleb Natapov]

On Thu, Mar 22, 2012 at 03:44:45PM +0800, Wen Congyang wrote:
> At 03/22/2012 03:31 PM, Gleb Natapov Wrote:
> > On Thu, Mar 22, 2012 at 09:05:12AM +0800, Wen Congyang wrote:
> >> At 03/22/2012 03:19 AM, Anthony Liguori Wrote:
> >>> On 03/21/2012 11:25 AM, 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.
> >>>
> >>> I think the use case here is pretty straight forward: if the guest finds
> >>> itself in bad place, it wants to indicate that to the host.
> >>>
> >>> We shouldn't rely on any device drivers or complex code.  It should be
> >>> as close to a single instruction as possible that can run even if
> >>> interrupts are disabled.
> >>>
> >>> An out instruction fits this very well.  I think a simple protocol like:
> >>
> >> This solution is more simple than using virtio-serial.
> >>
> >>>
> >>> inl PORT -> returns a magic number indicating the presence of qemucalls
> >>
> >> I donot understantd this instruction's purpose.
> >>
> >>> inl PORT+1 -> returns a bitmap of supported features
> >>
> >> Hmm, we can execute this instruction when guest starts. If the userspace
> >> does not process panicked event, there is no need to notify it.
> >>
> >>>
> >>> outl PORT+1 -> data reg1
> >>> outl PORT+2 -> data reg2
> >>> outl PORT+N -> data regN
> >>
> >> We can get the register value from vmcs. So there is no need to tell
> >> the register value to the host.
> >>
> > No device should examine register value. Ideally QEMU would read
> > registers only during migration.
> 
> I mean: if the qemu(or other app) want to know the register value, it can
> get it from vmcs. So there is no need to pass register value from guest
> to host.
> 
I understand what you mean and I am saying that reading register values
shouldn't be part of the protocol. Examining cpu state postmortem is OK
of course.

> Another question: each outl will cause vmexit?
> 
Yes, IIRC you can pass through io port to a guest but KVM doesn't do it.

> Thanks
> Wen Congyang
> 
> > 
> >> If we decide to avoid touching hypervisor, I agree with this solution.
> >>
> >> Thanks
> >> Wen Congyang
> >>>
> >>> outl PORT -> qemucall of index value with arguments 1..N
> >>>
> >>> Regards,
> >>>
> >>> Anthony Liguori
> >>>
> >>>>
> >>>> In fact the feature can be implemented 100% host side by searching for a
> >>>> panic string signature in the console logs.
> >>>>
> >>>
> >>> -- 
> >>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >>> the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>> Please read the FAQ at  http://www.tux.org/lkml/
> >>>
> > 
> > --
> > 			Gleb.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 

--
			Gleb.

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Gleb Natapov]

On Wed, Mar 21, 2012 at 02:19:34PM -0500, Anthony Liguori wrote:
> On 03/21/2012 11:25 AM, 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.
> 
> I think the use case here is pretty straight forward: if the guest
> finds itself in bad place, it wants to indicate that to the host.
> 
> We shouldn't rely on any device drivers or complex code.  It should
> be as close to a single instruction as possible that can run even if
> interrupts are disabled.
> 
> An out instruction fits this very well.  I think a simple protocol like:
> 
> inl PORT -> returns a magic number indicating the presence of qemucalls
> inl PORT+1 -> returns a bitmap of supported features
> 
Sigh, one more PV isa device.

> outl PORT+1 -> data reg1
> outl PORT+2 -> data reg2
> outl PORT+N -> data regN
> 
> outl PORT -> qemucall of index value with arguments 1..N
And you think you can trust panicked SMP guest to not call this on
multiple cpus simultaneously?

> 
> Regards,
> 
> Anthony Liguori
> 
> >
> >In fact the feature can be implemented 100% host side by searching for a
> >panic string signature in the console logs.
> >

--
			Gleb.

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

At 03/22/2012 03:28 PM, Gleb Natapov Wrote:
> On Wed, Mar 21, 2012 at 02:19:34PM -0500, Anthony Liguori wrote:
>> On 03/21/2012 11:25 AM, 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.
>>
>> I think the use case here is pretty straight forward: if the guest
>> finds itself in bad place, it wants to indicate that to the host.
>>
>> We shouldn't rely on any device drivers or complex code.  It should
>> be as close to a single instruction as possible that can run even if
>> interrupts are disabled.
>>
>> An out instruction fits this very well.  I think a simple protocol like:
>>
>> inl PORT -> returns a magic number indicating the presence of qemucalls
>> inl PORT+1 -> returns a bitmap of supported features
>>
> Sigh, one more PV isa device.
> 
>> outl PORT+1 -> data reg1
>> outl PORT+2 -> data reg2
>> outl PORT+N -> data regN
>>
>> outl PORT -> qemucall of index value with arguments 1..N
> And you think you can trust panicked SMP guest to not call this on
> multiple cpus simultaneously?

We can register panic notifier in the guest kernel, and do it in the panic
notifier callback.

Thanks
Wen Congyang

> 
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>>
>>> In fact the feature can be implemented 100% host side by searching for a
>>> panic string signature in the console logs.
>>>
> 
> --
> 			Gleb.
> 
> 

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Wen Congyang]

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 majordomo@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked

[Amit Shah]

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