kvm: notify host when guest panicked
PATCH 1/1 kvm: notify host when guest panicked
We can know the guest is panicked 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 panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.
We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.
We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when startint the kernel
--- arch/ia64/include/asm/kvm_para.h | 5 +++++ arch/powerpc/include/asm/kvm_para.h | 5 +++++ arch/s390/include/asm/kvm_para.h | 5 +++++ arch/x86/include/asm/kvm_para.h | 7 +++++++ arch/x86/kernel/kvm.c | 14 ++++++++++++++ include/linux/kvm_para.h | 15 +++++++++++++++ 6 files changed, 51 insertions(+), 0 deletions(-)
arch/ia64/include/asm/kvm_para.h +5 -0
@@ -26,6 +26,11 @@ static inline unsigned int kvm_arch_para_features(void)return 0 ; } +static inline unsigned int kvm_arch_pv_features (void ) +{ +return 0 ; +} +#endif #endif
arch/powerpc/include/asm/kvm_para.h +5 -0
@@ -206,6 +206,11 @@ static inline unsigned int kvm_arch_para_features(void)return r; } +static inline unsigned int kvm_arch_pv_features (void ) +{ +return 0 ; +} +#endif /* __KERNEL__ */ #endif /* __POWERPC_KVM_PARA_H__ */
arch/s390/include/asm/kvm_para.h +5 -0
@@ -149,6 +149,11 @@ static inline unsigned int kvm_arch_para_features(void)return 0 ; } +static inline unsigned int kvm_arch_pv_features (void ) +{ +return 0 ; +} +#endif #endif /* __S390_KVM_PARA_H */
arch/x86/include/asm/kvm_para.h +7 -0
@@ -208,6 +208,13 @@ static inline void kvm_disable_steal_time(void) }#endif +#ifdef KVM_PV_PORT +static inline unsigned int kvm_arch_pv_features (void ) +{ +return inl (KVM_PV_PORT ); +} +#endif +#endif /* __KERNEL__ */ #endif /* _ASM_X86_KVM_PARA_H */
arch/x86/kernel/kvm.c +14 -0
@@ -335,6 +335,17 @@ static struct notifier_block kvm_pv_reboot_nb = { .notifier_call = kvm_pv_reboot_notify, }; +static int +kvm_pv_panic_notify (struct notifier_block *nb,unsigned long code,void *unused) +{ +outl (KVM_PV_PANICKED ,KVM_PV_PORT ); +return NOTIFY_DONE ; +} + +static struct notifier_block kvm_pv_panic_nb = { + .notifier_call = kvm_pv_panic_notify, +}; +static u64 kvm_steal_clock (int cpu) {u64 steal;
@@ -421,6 +432,9 @@ void __init kvm_guest_init(void)paravirt_ops_setup ();register_reboot_notifier (&kvm_pv_reboot_nb); +if (kvm_pv_has_feature (KVM_PV_FEATURE_PANICKED )) +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 ))
include/linux/kvm_para.h +15 -0
@@ -20,6 +20,14 @@#define KVM_HC_FEATURES 3#define KVM_HC_PPC_MAP_MAGIC_PAGE 4 +#define KVM_PV_PORT (0x505UL) + +/* The bit of the value read from KVM_PV_PORT */ +#define KVM_PV_FEATURE_PANICKED 0 + +/* The value writen to KVM_PV_PORT */ +#define KVM_PV_PANICKED 1 +/* * hypercalls use architecture specific */
@@ -33,5 +41,12 @@ static inline int kvm_para_has_feature(unsigned int feature)return 1 ;return 0 ; } + +static inline int kvm_pv_has_feature (unsigned int feature) +{ +if (kvm_arch_pv_features () & (1UL << feature)) +return 1 ; +return 0 ; +}#endif /* __KERNEL__ */ #endif /* __LINUX_KVM_PARA_H */
Signature · 1 line
1.7.1
PATCH 1/3 start vm after reseting it
The guest should run after reseting it, but it does not run if its old state is RUN_STATE_INTERNAL_ERROR or RUN_STATE_PAUSED.
--- vl.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
vl.c +1 -0
@@ -1539,6 +1539,7 @@ static bool main_loop_should_exit(void)if (runstate_check (RUN_STATE_INTERNAL_ERROR ) ||runstate_check (RUN_STATE_SHUTDOWN )) {runstate_set (RUN_STATE_PAUSED ); +vm_start (); } }if (qemu_powerdown_requested ()) {
Signature · 1 line
1.7.1
Re: [Qemu-devel] [PATCH 1/3] start vm after reseting it
Quoted 13 lines · On Mon, 21 May 2012 14:49:32 +0800 Wen Congyang <[email protected]> wrote:
The guest should run after reseting it, but it does not run if its old state is
RUN_STATE_INTERNAL_ERRORorRUN_STATE_PAUSED.Signed-off-by Wen Congyang <[email protected]>--- vl.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)vl.c +0
-0
vl.c static bool main_loop_should_exit(void) · line 1542
Quoted 4 lines
vl.c +1
-0@@ -1539,6 +1539,7 @@ static bool main_loop_should_exit(void)if (runstate_check (RUN_STATE_INTERNAL_ERROR ) ||runstate_check (RUN_STATE_SHUTDOWN )) {runstate_set (RUN_STATE_PAUSED ); +vm_start ();
Please, drop the runstate_set() call. I think you also have to to call bdrv_iostatus_reset(), as qmp_cont() does.
Quoted 3 lines
vl.c +0
-0} }if (qemu_powerdown_requested ()) {
Re: [Qemu-devel] [PATCH 1/3] start vm after reseting it
At 05/31/2012 03:17 AM, Luiz Capitulino Wrote:
Quoted 11 lines
Quoted 8 lines · On Mon, 21 May 2012 14:49:32 +0800 Wen Congyang <[email protected]> wrote:
The guest should run after reseting it, but it does not run if its old state is
RUN_STATE_INTERNAL_ERRORorRUN_STATE_PAUSED.Signed-off-by Wen Congyang <[email protected]>--- vl.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
Quoted 12 lines
vl.c static bool main_loop_should_exit(void) · line 1542
Quoted 9 lines
vl.c +1
-0@@ -1539,6 +1539,7 @@ static bool main_loop_should_exit(void)if (runstate_check (RUN_STATE_INTERNAL_ERROR ) ||runstate_check (RUN_STATE_SHUTDOWN )) {runstate_set (RUN_STATE_PAUSED ); +vm_start ();Please, drop the
runstate_set()call. I think you also have to to callbdrv_iostatus_reset(), asqmp_cont()does.
I am not sure whether we should call it here. I think you may be right, so I will do it as you suggested.
Thanks
Wen Congyang
Quoted 11 lines
vl.c static bool main_loop_should_exit(void) · line 1545
Quoted 4 lines
vl.c +0
-0} }if (qemu_powerdown_requested ()) {--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
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 1/3] start vm after reseting it
In reply to Luiz CapitulinoAt 05/31/2012 03:17 AM, Luiz Capitulino Wrote:
Quoted 11 lines
Quoted 8 lines · On Mon, 21 May 2012 14:49:32 +0800 Wen Congyang <[email protected]> wrote:
The guest should run after reseting it, but it does not run if its old state is
RUN_STATE_INTERNAL_ERRORorRUN_STATE_PAUSED.Signed-off-by Wen Congyang <[email protected]>--- vl.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
Quoted 12 lines
vl.c static bool main_loop_should_exit(void) · line 1542
Quoted 9 lines
vl.c +1
-0@@ -1539,6 +1539,7 @@ static bool main_loop_should_exit(void)if (runstate_check (RUN_STATE_INTERNAL_ERROR ) ||runstate_check (RUN_STATE_SHUTDOWN )) {runstate_set (RUN_STATE_PAUSED ); +vm_start ();Please, drop the
runstate_set()call. I think you also have to to callbdrv_iostatus_reset(), asqmp_cont()does.
Hmm, if we drop the runstate_set() call here, we should update runstate_transitions_def too.
Thanks
Wen Congyang
Quoted 11 lines
vl.c static bool main_loop_should_exit(void) · line 1545
Quoted 4 lines
vl.c +0
-0} }if (qemu_powerdown_requested ()) {--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PATCH 2/3 update linux headers
In reply to Wen Congyang--- linux-headers/linux/kvm_para.h | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
linux-headers/linux/kvm_para.h +8 -0
@@ -20,6 +20,14 @@#define KVM_HC_FEATURES 3#define KVM_HC_PPC_MAP_MAGIC_PAGE 4 +#define KVM_PV_PORT (0x505UL) + +/* The bit of the value read from KVM_PV_PORT */ +#define KVM_PV_FEATURE_PANICKED 0 + +/* The value writen to KVM_PV_PORT */ +#define KVM_PV_PANICKED 1 +/* * hypercalls use architecture specific */
Signature · 1 line
1.7.1
PATCH 3/3 deal with guest panicked event
In reply to Wen CongyangWhen the guest is panicked, it will write 0x1 to the port 0x505. So if qemu reads 0x1 from this port, we can do the folloing three things according to the parameter -onpanic:
1. emit QEVENT_GUEST_PANICKED only
2. emit QEVENT_GUEST_PANICKED and pause VM
3. emit QEVENT_GUEST_PANICKED and quit VM
Note: if we emit QEVENT_GUEST_PANICKED only, and the management application does not receive this event(the management may not run when the event is emitted), the management won't know the guest is panicked.
--- kvm-all.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ kvm-stub.c | 9 ++++++ kvm.h | 3 ++ monitor.c | 3 ++ monitor.h | 1 + qapi-schema.json | 6 +++- qemu-options.hx | 14 +++++++++ qmp.c | 3 +- vl.c | 17 ++++++++++- 9 files changed, 137 insertions(+), 3 deletions(-)
kvm-all.c +84 -0
@@ -19,6 +19,7 @@#include <stdarg.h> #include <linux/kvm.h> +#include <linux/kvm_para.h> #include "qemu-common.h" #include "qemu-barrier.h"
@@ -29,6 +30,8 @@#include "bswap.h" #include "memory.h" #include "exec-memory.h" +#include "iorange.h" +#include "qemu-objects.h" /* This check must be after config-host.h is included */ #ifdef CONFIG_EVENTFD
@@ -1707,3 +1710,84 @@ int kvm_on_sigbus(int code, void *addr) {return kvm_arch_on_sigbus (code, addr); } + +/* Possible values for action parameter. */ +#define PANICKED_REPORT 1/* emit QEVENT_GUEST_PANICKED only */ +#define PANICKED_PAUSE 2/* emit QEVENT_GUEST_PANICKED and pause VM */ +#define PANICKED_QUIT 3/* emit QEVENT_GUEST_PANICKED and quit VM */ + +static int panicked_action =PANICKED_REPORT ; + +static void kvm_pv_port_read (IORange *iorange,uint64_t offset,unsigned width, +uint64_t *data) +{ + *data = (1 <<KVM_PV_FEATURE_PANICKED ); +} + +static void panicked_mon_event (const char *action) +{ +QObject *data; + + data =qobject_from_jsonf ("{ 'action': %s }" , action); +monitor_protocol_event (QEVENT_GUEST_PANICKED , data); +qobject_decref (data); +} + +static void panicked_perform_action (void ) +{ +switch (panicked_action) { +case PANICKED_REPORT : +panicked_mon_event ("report" ); +break ; + +case PANICKED_PAUSE : +panicked_mon_event ("pause" ); +vm_stop (RUN_STATE_GUEST_PANICKED ); +break ; + +case PANICKED_QUIT : +panicked_mon_event ("quit" ); +exit (0 ); +break ; + } +} + +static void kvm_pv_port_write (IORange *iorange,uint64_t offset,unsigned width, +uint64_t data) +{ +if (data ==KVM_PV_PANICKED ) +panicked_perform_action (); +} + +static void kvm_pv_port_destructor (IORange *iorange) +{ +g_free (iorange); +} + +static IORangeOps pv_io_range_ops = { + .read = kvm_pv_port_read, + .write = kvm_pv_port_write, + .destructor = kvm_pv_port_destructor, +}; + +void kvm_pv_port_init (void ) +{ +IORange *pv_io_range =g_malloc (sizeof (IORange)); + +iorange_init (pv_io_range, &pv_io_range_ops,0x505 ,1 ); +ioport_register (pv_io_range); +} + +int select_panicked_action (const char *p) +{ +if (strcasecmp (p,"report" ) ==0 ) + panicked_action =PANICKED_REPORT ; +else if (strcasecmp (p,"pause" ) ==0 ) + panicked_action =PANICKED_PAUSE ; +else if (strcasecmp (p,"quit" ) ==0 ) + panicked_action =PANICKED_QUIT ; +else +return -1 ; + +return 0 ; +}
kvm-stub.c +9 -0
@@ -128,3 +128,12 @@ int kvm_on_sigbus(int code, void *addr) {return 1 ; } + +void kvm_pv_port_init (void ) +{ +} + +int select_panicked_action (const char *p) +{ +return -1 ; +}
kvm.h +3 -0
@@ -60,6 +60,9 @@ int kvm_has_gsi_routing(void);int kvm_allows_irq0_override (void ); +void kvm_pv_port_init (void ); +int select_panicked_action (const char *p); +#ifdef NEED_CPU_H int kvm_init_vcpu (CPUArchState *env);
monitor.c +3 -0
@@ -493,6 +493,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 ;
monitor.h +1 -0
@@ -41,6 +41,7 @@ typedef enum MonitorEvent {QEVENT_DEVICE_TRAY_MOVED ,QEVENT_SUSPEND ,QEVENT_WAKEUP , +QEVENT_GUEST_PANICKED ,QEVENT_MAX , } MonitorEvent;
qapi-schema.json +5 -1
@@ -119,11 +119,15 @@ # @suspended: guest is suspended (ACPI S3) # # @watchdog: the watchdog action is configured to pause and has been triggered +# +# @guest-panicked: the panicked action is configured to pause and has been +# triggered. ## { 'enum': 'RunState', 'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused', 'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm', - 'running', 'save-vm', 'shutdown', 'suspended', 'watchdog' ] } + 'running', 'save-vm', 'shutdown', 'suspended', 'watchdog', + 'guest-panicked' ] } ## # @StatusInfo:
qemu-options.hx +14 -0
@@ -2743,6 +2743,20 @@ DEF("qtest-log", HAS_ARG, QEMU_OPTION_qtest_log, "-qtest-log LOG specify tracing options\n", QEMU_ARCH_ALL) +DEF("onpanic", HAS_ARG, QEMU_OPTION_onpanic, \ + "-onpanic report|pause|quit\n" \ + " action when the guest is panicked [default=report]", + QEMU_ARCH_ALL) +STEXI +@item -onpanic @var{action} + +The @var{action} controls what QEmu will do when the guest is panicked. +The default is @code{report} (emit QEVENT_GUEST_PANICKED only). +Other possible actions are: +@code{pause} (emit QEVENT_GUEST_PANICKED and pause VM), +@code{quit} (emit QEVENT_GUEST_PANICKED and quit VM). +ETEXI + HXCOMM This is the last statement. Insert new options before this line! STEXI @end table
qmp.c +2 -1
@@ -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_GUEST_PANICKED )) {error_set (errp,QERR_RESET_REQUIRED );return ; }else if (runstate_check (RUN_STATE_SUSPENDED )) {
vl.c +16 -1
@@ -367,6 +367,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_GUEST_PANICKED }, { RUN_STATE_SAVE_VM, RUN_STATE_RUNNING },
@@ -381,6 +382,9 @@ static const RunStateTransition runstate_transitions_def[] = { { RUN_STATE_WATCHDOG, RUN_STATE_RUNNING }, { RUN_STATE_WATCHDOG, RUN_STATE_FINISH_MIGRATE }, + { RUN_STATE_GUEST_PANICKED, RUN_STATE_PAUSED }, + { RUN_STATE_GUEST_PANICKED, RUN_STATE_FINISH_MIGRATE }, + { RUN_STATE_MAX, RUN_STATE_MAX }, };
@@ -1537,7 +1541,8 @@ static bool main_loop_should_exit(void)qemu_system_reset (VMRESET_REPORT );resume_all_vcpus ();if (runstate_check (RUN_STATE_INTERNAL_ERROR ) || -runstate_check (RUN_STATE_SHUTDOWN )) { +runstate_check (RUN_STATE_SHUTDOWN ) || +runstate_check (RUN_STATE_GUEST_PANICKED )) {runstate_set (RUN_STATE_PAUSED );vm_start (); }
@@ -3202,6 +3207,12 @@ int main(int argc, char **argv, char **envp)case QEMU_OPTION_qtest_log: qtest_log = optarg;break ; +case QEMU_OPTION_onpanic: +if (select_panicked_action (optarg) ==-1 ) { +fprintf (stderr,"Unknown -onpanic parameter\n" ); +exit (1 ); + } +break ;default :os_parse_cmd_args (popt->index, optarg); }
@@ -3634,6 +3645,10 @@ int main(int argc, char **argv, char **envp) } } +if (kvm_enabled ()) { +kvm_pv_port_init (); + } +if (incoming) {Error *errp =NULL ;int ret =qemu_start_incoming_migration (incoming, &errp);
Signature · 1 line
1.7.1
Re: [PATCH 3/3] deal with guest panicked event
Quoted 106 lines · Wen Congyang
When the guest is panicked, it will write
0x1to the port0x505. So if qemu reads0x1from this port, we can do the folloing three things according to the parameter -onpanic:
1. emitQEVENT_GUEST_PANICKEDonly
2. emitQEVENT_GUEST_PANICKEDand pause VM
3. emitQEVENT_GUEST_PANICKEDand quit VMNote: if we emit
QEVENT_GUEST_PANICKEDonly, and the management application does not receive this event(the management may not run when the event is emitted), the management won't know the guest is panicked.Signed-off-by Wen Congyang <[email protected]>--- kvm-all.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ kvm-stub.c | 9 ++++++ kvm.h | 3 ++ monitor.c | 3 ++ monitor.h | 1 + qapi-schema.json | 6 +++- qemu-options.hx | 14 +++++++++ qmp.c | 3 +- vl.c | 17 ++++++++++- 9 files changed, 137 insertions(+), 3 deletions(-)kvm-all.c +59
-0@@ -19,6 +19,7 @@#include <stdarg.h> #include <linux/kvm.h> +#include <linux/kvm_para.h> #include "qemu-common.h" #include "qemu-barrier.h" @@ -29,6 +30,8 @@#include "bswap.h" #include "memory.h" #include "exec-memory.h" +#include "iorange.h" +#include "qemu-objects.h" /* This check must be after config-host.h is included */ #ifdef CONFIG_EVENTFD @@ -1707,3 +1710,84 @@ int kvm_on_sigbus(int code, void *addr) {return kvm_arch_on_sigbus (code, addr); } + +/* Possible values for action parameter. */ +#define PANICKED_REPORT 1/* emit QEVENT_GUEST_PANICKED only */ +#define PANICKED_PAUSE 2/* emit QEVENT_GUEST_PANICKED and pause VM */ +#define PANICKED_QUIT 3/* emit QEVENT_GUEST_PANICKED and quit VM */ + +static int panicked_action =PANICKED_REPORT ; + +static void kvm_pv_port_read (IORange *iorange,uint64_t offset,unsigned width, +uint64_t *data) +{ + *data = (1 <<KVM_PV_FEATURE_PANICKED ); +} + +static void panicked_mon_event (const char *action) +{ +QObject *data; + + data =qobject_from_jsonf ("{ 'action': %s }" , action); +monitor_protocol_event (QEVENT_GUEST_PANICKED , data); +qobject_decref (data); +} + +static void panicked_perform_action (void ) +{ +switch (panicked_action) { +case PANICKED_REPORT : +panicked_mon_event ("report" ); +break ; + +case PANICKED_PAUSE : +panicked_mon_event ("pause" ); +vm_stop (RUN_STATE_GUEST_PANICKED ); +break ; + +case PANICKED_QUIT : +panicked_mon_event ("quit" ); +exit (0 ); +break ; + } +} + +static void kvm_pv_port_write (IORange *iorange,uint64_t offset,unsigned width, +uint64_t data) +{ +if (data ==KVM_PV_PANICKED ) +panicked_perform_action (); +} + +static void kvm_pv_port_destructor (IORange *iorange) +{ +g_free (iorange); +} + +static IORangeOps pv_io_range_ops = { + .read = kvm_pv_port_read,
kvm-all.c int kvm_on_sigbus(int code, void *addr) · line 1778
Quoted 10 lines
kvm-all.c +10
-0+ .write = kvm_pv_port_write, + .destructor = kvm_pv_port_destructor, +}; + +void kvm_pv_port_init (void ) +{ +IORange *pv_io_range =g_malloc (sizeof (IORange)); + +iorange_init (pv_io_range, &pv_io_range_ops,0x505 ,1 ); +ioport_register (pv_io_range);
Not sure if the discussion about the PV channel already settled, but if PIO is the way to go, please model this as a proper QEMU device (e.g. "panic", implemented in hw/kvm/panic.c), not just an open-coded PIO range.
Jan
PS: checkpatch.pl...
Signature · 2 lines
Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 3/3] deal with guest panicked event
In reply to Wen CongyangQuoted 11 lines · On Mon, 21 May 2012 14:50:51 +0800 Wen Congyang <[email protected]> wrote:
When the guest is panicked, it will write
0x1to the port0x505. So if qemu reads0x1from this port, we can do the folloing three things according to the parameter -onpanic:
1. emitQEVENT_GUEST_PANICKEDonly
2. emitQEVENT_GUEST_PANICKEDand pause VM
3. emitQEVENT_GUEST_PANICKEDand quit VMNote: if we emit
QEVENT_GUEST_PANICKEDonly, and the management application does not receive this event(the management may not run when the event is emitted), the management won't know the guest is panicked.
It will if it checks the vm status.
Btw, please, split this further into a patch adding the event, another one adding the new runstate and then the rest. One more comment below.
Quoted 69 lines
Signed-off-by Wen Congyang <[email protected]>--- kvm-all.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ kvm-stub.c | 9 ++++++ kvm.h | 3 ++ monitor.c | 3 ++ monitor.h | 1 + qapi-schema.json | 6 +++- qemu-options.hx | 14 +++++++++ qmp.c | 3 +- vl.c | 17 ++++++++++- 9 files changed, 137 insertions(+), 3 deletions(-)kvm-all.c +33
-0@@ -19,6 +19,7 @@#include <stdarg.h> #include <linux/kvm.h> +#include <linux/kvm_para.h> #include "qemu-common.h" #include "qemu-barrier.h" @@ -29,6 +30,8 @@#include "bswap.h" #include "memory.h" #include "exec-memory.h" +#include "iorange.h" +#include "qemu-objects.h" /* This check must be after config-host.h is included */ #ifdef CONFIG_EVENTFD @@ -1707,3 +1710,84 @@ int kvm_on_sigbus(int code, void *addr) {return kvm_arch_on_sigbus (code, addr); } + +/* Possible values for action parameter. */ +#define PANICKED_REPORT 1/* emit QEVENT_GUEST_PANICKED only */ +#define PANICKED_PAUSE 2/* emit QEVENT_GUEST_PANICKED and pause VM */ +#define PANICKED_QUIT 3/* emit QEVENT_GUEST_PANICKED and quit VM */ + +static int panicked_action =PANICKED_REPORT ; + +static void kvm_pv_port_read (IORange *iorange,uint64_t offset,unsigned width, +uint64_t *data) +{ + *data = (1 <<KVM_PV_FEATURE_PANICKED ); +} + +static void panicked_mon_event (const char *action) +{ +QObject *data; + + data =qobject_from_jsonf ("{ 'action': %s }" , action); +monitor_protocol_event (QEVENT_GUEST_PANICKED , data); +qobject_decref (data); +} + +static void panicked_perform_action (void ) +{ +switch (panicked_action) { +case PANICKED_REPORT : +panicked_mon_event ("report" ); +break ; +
kvm-all.c int kvm_on_sigbus(int code, void *addr) · line 1752
Quoted 10 lines
kvm-all.c +10
-0+case PANICKED_PAUSE : +panicked_mon_event ("pause" ); +vm_stop (RUN_STATE_GUEST_PANICKED ); +break ; + +case PANICKED_QUIT : +panicked_mon_event ("quit" ); +exit (0 ); +break ; + }
Having the data argument is not needed/wanted. The mngt app can guess it if it needs to know it, but I think it doesn't want to.
Quoted 214 lines
kvm-all.c +41
-0+} + +static void kvm_pv_port_write (IORange *iorange,uint64_t offset,unsigned width, +uint64_t data) +{ +if (data ==KVM_PV_PANICKED ) +panicked_perform_action (); +} + +static void kvm_pv_port_destructor (IORange *iorange) +{ +g_free (iorange); +} + +static IORangeOps pv_io_range_ops = { + .read = kvm_pv_port_read, + .write = kvm_pv_port_write, + .destructor = kvm_pv_port_destructor, +}; + +void kvm_pv_port_init (void ) +{ +IORange *pv_io_range =g_malloc (sizeof (IORange)); + +iorange_init (pv_io_range, &pv_io_range_ops,0x505 ,1 ); +ioport_register (pv_io_range); +} + +int select_panicked_action (const char *p) +{ +if (strcasecmp (p,"report" ) ==0 ) + panicked_action =PANICKED_REPORT ; +else if (strcasecmp (p,"pause" ) ==0 ) + panicked_action =PANICKED_PAUSE ; +else if (strcasecmp (p,"quit" ) ==0 ) + panicked_action =PANICKED_QUIT ; +else +return -1 ; + +return 0 ; +}kvm-stub.c +9
-0@@ -128,3 +128,12 @@ int kvm_on_sigbus(int code, void *addr) {return 1 ; } + +void kvm_pv_port_init (void ) +{ +} + +int select_panicked_action (const char *p) +{ +return -1 ; +}kvm.h +3
-0@@ -60,6 +60,9 @@ int kvm_has_gsi_routing(void);int kvm_allows_irq0_override (void ); +void kvm_pv_port_init (void ); +int select_panicked_action (const char *p); +#ifdef NEED_CPU_H int kvm_init_vcpu (CPUArchState *env);monitor.c +3
-0@@ -493,6 +493,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 ;monitor.h +1
-0@@ -41,6 +41,7 @@ typedef enum MonitorEvent {QEVENT_DEVICE_TRAY_MOVED ,QEVENT_SUSPEND ,QEVENT_WAKEUP , +QEVENT_GUEST_PANICKED ,QEVENT_MAX , } MonitorEvent;qapi-schema.json +5
-1@@ -119,11 +119,15 @@ # @suspended: guest is suspended (ACPI S3) # # @watchdog: the watchdog action is configured to pause and has been triggered +# +# @guest-panicked: the panicked action is configured to pause and has been +# triggered. ## { 'enum': 'RunState', 'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused', 'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm', - 'running', 'save-vm', 'shutdown', 'suspended', 'watchdog' ] } + 'running', 'save-vm', 'shutdown', 'suspended', 'watchdog', + 'guest-panicked' ] } ## # @StatusInfo:qemu-options.hx +14
-0@@ -2743,6 +2743,20 @@ DEF("qtest-log", HAS_ARG, QEMU_OPTION_qtest_log, "-qtest-log LOG specify tracing options\n", QEMU_ARCH_ALL) +DEF("onpanic", HAS_ARG, QEMU_OPTION_onpanic, \ + "-onpanic report|pause|quit\n" \ + " action when the guest is panicked [default=report]", + QEMU_ARCH_ALL) +STEXI +@item -onpanic @var{action} + +The @var{action} controls what QEmu will do when the guest is panicked. +The default is @code{report} (emit QEVENT_GUEST_PANICKED only). +Other possible actions are: +@code{pause} (emit QEVENT_GUEST_PANICKED and pause VM), +@code{quit} (emit QEVENT_GUEST_PANICKED and quit VM). +ETEXI + HXCOMM This is the last statement. Insert new options before this line! STEXI @end tableqmp.c +2
-1@@ -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_GUEST_PANICKED )) {error_set (errp,QERR_RESET_REQUIRED );return ; }else if (runstate_check (RUN_STATE_SUSPENDED )) {vl.c +16
-1@@ -367,6 +367,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_GUEST_PANICKED }, { RUN_STATE_SAVE_VM, RUN_STATE_RUNNING },@@ -381,6 +382,9 @@ static const RunStateTransition runstate_transitions_def[] = { { RUN_STATE_WATCHDOG, RUN_STATE_RUNNING }, { RUN_STATE_WATCHDOG, RUN_STATE_FINISH_MIGRATE }, + { RUN_STATE_GUEST_PANICKED, RUN_STATE_PAUSED }, + { RUN_STATE_GUEST_PANICKED, RUN_STATE_FINISH_MIGRATE }, + { RUN_STATE_MAX, RUN_STATE_MAX }, };@@ -1537,7 +1541,8 @@ static bool main_loop_should_exit(void)qemu_system_reset (VMRESET_REPORT );resume_all_vcpus ();if (runstate_check (RUN_STATE_INTERNAL_ERROR ) || -runstate_check (RUN_STATE_SHUTDOWN )) { +runstate_check (RUN_STATE_SHUTDOWN ) || +runstate_check (RUN_STATE_GUEST_PANICKED )) {runstate_set (RUN_STATE_PAUSED );vm_start (); }@@ -3202,6 +3207,12 @@ int main(int argc, char **argv, char **envp)case QEMU_OPTION_qtest_log: qtest_log = optarg;break ; +case QEMU_OPTION_onpanic: +if (select_panicked_action (optarg) ==-1 ) { +fprintf (stderr,"Unknown -onpanic parameter\n" ); +exit (1 ); + } +break ;default :os_parse_cmd_args (popt->index, optarg); }@@ -3634,6 +3645,10 @@ int main(int argc, char **argv, char **envp) } } +if (kvm_enabled ()) { +kvm_pv_port_init (); + } +if (incoming) {Error *errp =NULL ;int ret =qemu_start_incoming_migration (incoming, &errp);
Re: [Qemu-devel] [PATCH 3/3] deal with guest panicked event
At 05/31/2012 03:23 AM, Luiz Capitulino Wrote:
Quoted 15 lines
Quoted 11 lines · On Mon, 21 May 2012 14:50:51 +0800 Wen Congyang <[email protected]> wrote:
When the guest is panicked, it will write
0x1to the port0x505. So if qemu reads0x1from this port, we can do the folloing three things according to the parameter -onpanic:
1. emitQEVENT_GUEST_PANICKEDonly
2. emitQEVENT_GUEST_PANICKEDand pause VM
3. emitQEVENT_GUEST_PANICKEDand quit VMNote: if we emit
QEVENT_GUEST_PANICKEDonly, and the management application does not receive this event(the management may not run when the event is emitted), the management won't know the guest is panicked.
Quoted 4 lines
It will if it checks the vm status.
Btw, please, split this further into a patch adding the event, another one adding the new runstate and then the rest. One more comment below.
OK, I will split it.
Quoted 75 lines
Quoted 75 lines
Signed-off-by Wen Congyang <[email protected]>--- kvm-all.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ kvm-stub.c | 9 ++++++ kvm.h | 3 ++ monitor.c | 3 ++ monitor.h | 1 + qapi-schema.json | 6 +++- qemu-options.hx | 14 +++++++++ qmp.c | 3 +- vl.c | 17 ++++++++++- 9 files changed, 137 insertions(+), 3 deletions(-)kvm-all.c +38
-0@@ -19,6 +19,7 @@#include <stdarg.h> #include <linux/kvm.h> +#include <linux/kvm_para.h> #include "qemu-common.h" #include "qemu-barrier.h" @@ -29,6 +30,8 @@#include "bswap.h" #include "memory.h" #include "exec-memory.h" +#include "iorange.h" +#include "qemu-objects.h" /* This check must be after config-host.h is included */ #ifdef CONFIG_EVENTFD @@ -1707,3 +1710,84 @@ int kvm_on_sigbus(int code, void *addr) {return kvm_arch_on_sigbus (code, addr); } + +/* Possible values for action parameter. */ +#define PANICKED_REPORT 1/* emit QEVENT_GUEST_PANICKED only */ +#define PANICKED_PAUSE 2/* emit QEVENT_GUEST_PANICKED and pause VM */ +#define PANICKED_QUIT 3/* emit QEVENT_GUEST_PANICKED and quit VM */ + +static int panicked_action =PANICKED_REPORT ; + +static void kvm_pv_port_read (IORange *iorange,uint64_t offset,unsigned width, +uint64_t *data) +{ + *data = (1 <<KVM_PV_FEATURE_PANICKED ); +} + +static void panicked_mon_event (const char *action) +{ +QObject *data; + + data =qobject_from_jsonf ("{ 'action': %s }" , action); +monitor_protocol_event (QEVENT_GUEST_PANICKED , data); +qobject_decref (data); +} + +static void panicked_perform_action (void ) +{ +switch (panicked_action) { +case PANICKED_REPORT : +panicked_mon_event ("report" ); +break ; + +case PANICKED_PAUSE : +panicked_mon_event ("pause" ); +vm_stop (RUN_STATE_GUEST_PANICKED ); +break ; +
Quoted 8 lines
kvm-all.c int kvm_on_sigbus(int code, void *addr) · line 1752
Quoted 5 lines
kvm-all.c +5
-0+case PANICKED_QUIT : +panicked_mon_event ("quit" ); +exit (0 ); +break ; + }Having the data argument is not needed/wanted. The mngt app can guess it if it needs to know it, but I think it doesn't want to.
Libvirt will do something when the kernel is panicked, so it should know the action in qemu side.
Thanks
Wen Congyang
Quoted 222 lines
Quoted 205 lines
kvm-all.c +41
-0+} + +static void kvm_pv_port_write (IORange *iorange,uint64_t offset,unsigned width, +uint64_t data) +{ +if (data ==KVM_PV_PANICKED ) +panicked_perform_action (); +} + +static void kvm_pv_port_destructor (IORange *iorange) +{ +g_free (iorange); +} + +static IORangeOps pv_io_range_ops = { + .read = kvm_pv_port_read, + .write = kvm_pv_port_write, + .destructor = kvm_pv_port_destructor, +}; + +void kvm_pv_port_init (void ) +{ +IORange *pv_io_range =g_malloc (sizeof (IORange)); + +iorange_init (pv_io_range, &pv_io_range_ops,0x505 ,1 ); +ioport_register (pv_io_range); +} + +int select_panicked_action (const char *p) +{ +if (strcasecmp (p,"report" ) ==0 ) + panicked_action =PANICKED_REPORT ; +else if (strcasecmp (p,"pause" ) ==0 ) + panicked_action =PANICKED_PAUSE ; +else if (strcasecmp (p,"quit" ) ==0 ) + panicked_action =PANICKED_QUIT ; +else +return -1 ; + +return 0 ; +}kvm-stub.c +9
-0@@ -128,3 +128,12 @@ int kvm_on_sigbus(int code, void *addr) {return 1 ; } + +void kvm_pv_port_init (void ) +{ +} + +int select_panicked_action (const char *p) +{ +return -1 ; +}kvm.h +3
-0@@ -60,6 +60,9 @@ int kvm_has_gsi_routing(void);int kvm_allows_irq0_override (void ); +void kvm_pv_port_init (void ); +int select_panicked_action (const char *p); +#ifdef NEED_CPU_H int kvm_init_vcpu (CPUArchState *env);monitor.c +3
-0@@ -493,6 +493,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 ;monitor.h +1
-0@@ -41,6 +41,7 @@ typedef enum MonitorEvent {QEVENT_DEVICE_TRAY_MOVED ,QEVENT_SUSPEND ,QEVENT_WAKEUP , +QEVENT_GUEST_PANICKED ,QEVENT_MAX , } MonitorEvent;qapi-schema.json +5
-1@@ -119,11 +119,15 @@ # @suspended: guest is suspended (ACPI S3) # # @watchdog: the watchdog action is configured to pause and has been triggered +# +# @guest-panicked: the panicked action is configured to pause and has been +# triggered. ## { 'enum': 'RunState', 'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused', 'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm', - 'running', 'save-vm', 'shutdown', 'suspended', 'watchdog' ] } + 'running', 'save-vm', 'shutdown', 'suspended', 'watchdog', + 'guest-panicked' ] } ## # @StatusInfo:qemu-options.hx +14
-0@@ -2743,6 +2743,20 @@ DEF("qtest-log", HAS_ARG, QEMU_OPTION_qtest_log, "-qtest-log LOG specify tracing options\n", QEMU_ARCH_ALL) +DEF("onpanic", HAS_ARG, QEMU_OPTION_onpanic, \ + "-onpanic report|pause|quit\n" \ + " action when the guest is panicked [default=report]", + QEMU_ARCH_ALL) +STEXI +@item -onpanic @var{action} + +The @var{action} controls what QEmu will do when the guest is panicked. +The default is @code{report} (emit QEVENT_GUEST_PANICKED only). +Other possible actions are: +@code{pause} (emit QEVENT_GUEST_PANICKED and pause VM), +@code{quit} (emit QEVENT_GUEST_PANICKED and quit VM). +ETEXI + HXCOMM This is the last statement. Insert new options before this line! STEXI @end tableqmp.c +2
-1@@ -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_GUEST_PANICKED )) {error_set (errp,QERR_RESET_REQUIRED );return ; }else if (runstate_check (RUN_STATE_SUSPENDED )) {vl.c +12
-1@@ -367,6 +367,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_GUEST_PANICKED }, { RUN_STATE_SAVE_VM, RUN_STATE_RUNNING },@@ -381,6 +382,9 @@ static const RunStateTransition runstate_transitions_def[] = { { RUN_STATE_WATCHDOG, RUN_STATE_RUNNING }, { RUN_STATE_WATCHDOG, RUN_STATE_FINISH_MIGRATE }, + { RUN_STATE_GUEST_PANICKED, RUN_STATE_PAUSED }, + { RUN_STATE_GUEST_PANICKED, RUN_STATE_FINISH_MIGRATE }, + { RUN_STATE_MAX, RUN_STATE_MAX }, };@@ -1537,7 +1541,8 @@ static bool main_loop_should_exit(void)qemu_system_reset (VMRESET_REPORT );resume_all_vcpus ();if (runstate_check (RUN_STATE_INTERNAL_ERROR ) || -runstate_check (RUN_STATE_SHUTDOWN )) { +runstate_check (RUN_STATE_SHUTDOWN ) || +runstate_check (RUN_STATE_GUEST_PANICKED )) {runstate_set (RUN_STATE_PAUSED );vm_start (); }@@ -3202,6 +3207,12 @@ int main(int argc, char **argv, char **envp)case QEMU_OPTION_qtest_log: qtest_log = optarg;break ; +case QEMU_OPTION_onpanic: +if (select_panicked_action (optarg) ==-1 ) { +fprintf (stderr,"Unknown -onpanic parameter\n" ); +exit (1 ); + } +break ;default :os_parse_cmd_args (popt->index, optarg); }vl.c int main(int argc, char **argv, char **envp) · line 3654
Quoted 10 lines
vl.c +4
-0@@ -3634,6 +3645,10 @@ int main(int argc, char **argv, char **envp) } } +if (kvm_enabled ()) { +kvm_pv_port_init (); + } +if (incoming) {Error *errp =NULL ;int ret =qemu_start_incoming_migration (incoming, &errp);--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
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 3/3] deal with guest panicked event
Quoted 21 lines · On Tue, 12 Jun 2012 14:55:37 +0800 Wen Congyang <[email protected]> wrote:
Quoted 12 lines
Quoted 12 lines
kvm-all.c +12
-0+static void panicked_perform_action (void ) +{ +switch (panicked_action) { +case PANICKED_REPORT : +panicked_mon_event ("report" ); +break ; + +case PANICKED_PAUSE : +panicked_mon_event ("pause" ); +vm_stop (RUN_STATE_GUEST_PANICKED ); +break ; +Quoted 8 lines
kvm-all.c int kvm_on_sigbus(int code, void *addr) · line 1752
Quoted 5 lines
kvm-all.c +5
-0+case PANICKED_QUIT : +panicked_mon_event ("quit" ); +exit (0 ); +break ; + }Having the data argument is not needed/wanted. The mngt app can guess it if it needs to know it, but I think it doesn't want to.
Quoted 2 lines
Libvirt will do something when the kernel is panicked, so it should know the action in qemu side.
But the action will be set by libvirt itself, no?
Re: [Qemu-devel] [PATCH 3/3] deal with guest panicked event
Quoted 24 lines · Luiz Capitulino
Quoted 21 lines · On Tue, 12 Jun 2012 14:55:37 +0800 Wen Congyang <[email protected]> wrote:
Quoted 20 lines
Quoted 7 lines
kvm-all.c +7
-0+static void panicked_perform_action (void ) +{ +switch (panicked_action) { +case PANICKED_REPORT : +panicked_mon_event ("report" ); +break ; +kvm-all.c int kvm_on_sigbus(int code, void *addr) · line 1752
Quoted 10 lines
kvm-all.c +10
-0+case PANICKED_PAUSE : +panicked_mon_event ("pause" ); +vm_stop (RUN_STATE_GUEST_PANICKED ); +break ; + +case PANICKED_QUIT : +panicked_mon_event ("quit" ); +exit (0 ); +break ; + }Having the data argument is not needed/wanted. The mngt app can guess it if it needs to know it, but I think it doesn't want to.
Quoted 4 lines
Quoted 2 lines
Libvirt will do something when the kernel is panicked, so it should know the action in qemu side.
But the action will be set by libvirt itself, no?
Sure, but the whole world isn't libvirt. If the process listening to the monitor is not the same as the process which launched the VM, then I think including the action is worthwhile. Besides, the way Wen has done this is identical to what we already do with QEVENT_WATCHDOG and I think it is desirable to keep consistency here.
Daniel
Signature · 4 lines
|: 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 3/3] deal with guest panicked event
Quoted 28 lines · On Tue, 12 Jun 2012 13:40:45 +0100 "Daniel P. Berrange" <[email protected]>…
Quoted 27 lines · Luiz Capitulino
Quoted 23 lines · On Tue, 12 Jun 2012 14:55:37 +0800 Wen Congyang <[email protected]> wrote:
Quoted 12 lines
Quoted 12 lines
kvm-all.c +12
-0+static void panicked_perform_action (void ) +{ +switch (panicked_action) { +case PANICKED_REPORT : +panicked_mon_event ("report" ); +break ; + +case PANICKED_PAUSE : +panicked_mon_event ("pause" ); +vm_stop (RUN_STATE_GUEST_PANICKED ); +break ; +Quoted 8 lines
kvm-all.c int kvm_on_sigbus(int code, void *addr) · line 1752
Quoted 5 lines
kvm-all.c +5
-0+case PANICKED_QUIT : +panicked_mon_event ("quit" ); +exit (0 ); +break ; + }Having the data argument is not needed/wanted. The mngt app can guess it if it needs to know it, but I think it doesn't want to.
Libvirt will do something when the kernel is panicked, so it should know the action in qemu side.
Quoted 7 lines
Quoted 1 line
But the action will be set by libvirt itself, no?
Sure, but the whole world isn't libvirt. If the process listening to the monitor is not the same as the process which launched the VM, then I think including the action is worthwhile. Besides, the way Wen has done this is identical to what we already do with
QEVENT_WATCHDOGand I think it is desirable to keep consistency here.
That's right, I had forgotten about the WATCHDOG event. Maybe it would make more sense to have this info in a query- command though, specially if we plan to have a command to change that setting.
But I won't oppose having it in the event.
Paolo Bonzini
maintainerRe: [PATCH 3/3] deal with guest panicked event
In reply to Wen CongyangIl 21/05/2012 08:50, Wen Congyang ha scritto:
qemu-options.hx DEF("qtest-log", HAS_ARG, QEMU_OPTION_qtest_log, · line 2754
Quoted 9 lines
qemu-options.hx +9
-0+DEF("onpanic", HAS_ARG, QEMU_OPTION_onpanic, \ + "-onpanic report|pause|quit\n" \ + " action when the guest is panicked [default=report]", + QEMU_ARCH_ALL) +STEXI +@item -onpanic @var{action} + +The @var{action} controls what QEmu will do when the guest is panicked. +The default is @code{report} (emit QEVENT_GUEST_PANICKED only).
-watchdog-action just calls this "none".
Quoted 3 lines
+Other possible actions are:
+@code{pause} (emitQEVENT_GUEST_PANICKEDand pause VM), +@code{quit} (emitQEVENT_GUEST_PANICKEDand quit VM).
Rather than just "quit", there should be choices for "shutdown", "poweroff" and "reset" for consistency with -watchdog-action.
Also, this option should also be accessible from "-machine", please.
Paolo
Quoted 5 lines
qemu-options.hx +2
-0+ETEXI + HXCOMM This is the last statement. Insert new options before this line! STEXI @end table
Re: [PATCH 3/3] deal with guest panicked event
At 06/12/2012 09:29 PM, Paolo Bonzini Wrote:
Quoted 12 lines
Il 21/05/2012 08:50, Wen Congyang ha scritto:
qemu-options.hx DEF("qtest-log", HAS_ARG, QEMU_OPTION_qtest_log, · line 2754
Quoted 9 lines
qemu-options.hx +9
-0+DEF("onpanic", HAS_ARG, QEMU_OPTION_onpanic, \ + "-onpanic report|pause|quit\n" \ + " action when the guest is panicked [default=report]", + QEMU_ARCH_ALL) +STEXI +@item -onpanic @var{action} + +The @var{action} controls what QEmu will do when the guest is panicked. +The default is @code{report} (emit QEVENT_GUEST_PANICKED only).-watchdog-action just calls this "none".
Yes, I will change the action name.
Quoted 7 lines
Quoted 4 lines
+Other possible actions are:
+@code{pause} (emitQEVENT_GUEST_PANICKEDand pause VM), +@code{quit} (emitQEVENT_GUEST_PANICKEDand quit VM).Rather than just "quit", there should be choices for "shutdown", "poweroff" and "reset" for consistency with -watchdog-action.
Hmm, quit means poweroff. I will add reset, but I think we donot need shutdown, because we cannot shutdown the system when it is panicked.
Quoted 2 lines
Also, this option should also be accessible from "-machine", please.
I don't understand this. Do you mean we can also specify this action in -machine option?
Thanks
Wen Congyang
Quoted 14 lines
Paolo
qemu-options.hx DEF("qtest-log", HAS_ARG, QEMU_OPTION_qtest_log, · line 2762
Quoted 5 lines
qemu-options.hx +2
-0+ETEXI + HXCOMM This is the last statement. Insert new options before this line! STEXI @end table--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Paolo Bonzini
maintainerRe: [PATCH 3/3] deal with guest panicked event
Il 13/06/2012 09:02, Wen Congyang ha scritto:
Quoted 9 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
+Other possible actions are:
+@code{pause} (emitQEVENT_GUEST_PANICKEDand pause VM), +@code{quit} (emitQEVENT_GUEST_PANICKEDand quit VM).Rather than just "quit", there should be choices for "shutdown", "poweroff" and "reset" for consistency with -watchdog-action.
Hmm, quit means poweroff. I will add reset, but I think we donot need shutdown, because we cannot shutdown the system when it is panicked.
Right. :)
Can you also rename quit to poweroff?
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Also, this option should also be accessible from "-machine", please.
I don't understand this. Do you mean we can also specify this action in -machine option?
Yes, like -machine panic_action=poweroff.
Paolo
Re: [PATCH 3/3] deal with guest panicked event
At 06/13/2012 03:53 PM, Paolo Bonzini Wrote:
Quoted 7 lines
Il 13/06/2012 09:02, Wen Congyang ha scritto:
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
+Other possible actions are:
+@code{pause} (emitQEVENT_GUEST_PANICKEDand pause VM), +@code{quit} (emitQEVENT_GUEST_PANICKEDand quit VM).Rather than just "quit", there should be choices for "shutdown", "poweroff" and "reset" for consistency with -watchdog-action.
Quoted 7 lines
Quoted 3 lines
Hmm, quit means poweroff. I will add reset, but I think we donot need shutdown, because we cannot shutdown the system when it is panicked.
Right. :)
Can you also rename quit to poweroff?
OK.
Thanks
Wen Congyang
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
Also, this option should also be accessible from "-machine", please.
I don't understand this. Do you mean we can also specify this action in -machine option?
Yes, like -machine panic_action=poweroff.
Paolo
Hi, Avi
Do you have any comment to this patch?
Thanks
Wen Congyang
At 05/21/2012 02:46 PM, Wen Congyang Wrote:
Quoted 159 lines
We can know the guest is panicked 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 panicked. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is panicked.We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when startint the kernelSigned-off-by Wen Congyang <[email protected]>--- arch/ia64/include/asm/kvm_para.h | 5 +++++ arch/powerpc/include/asm/kvm_para.h | 5 +++++ arch/s390/include/asm/kvm_para.h | 5 +++++ arch/x86/include/asm/kvm_para.h | 7 +++++++ arch/x86/kernel/kvm.c | 14 ++++++++++++++ include/linux/kvm_para.h | 15 +++++++++++++++ 6 files changed, 51 insertions(+), 0 deletions(-)arch/ia64/include/asm/kvm_para.h +5
-0@@ -26,6 +26,11 @@ static inline unsigned int kvm_arch_para_features(void)return 0 ; } +static inline unsigned int kvm_arch_pv_features (void ) +{ +return 0 ; +} +#endif #endif arch/powerpc/include/asm/kvm_para.h +5
-0@@ -206,6 +206,11 @@ static inline unsigned int kvm_arch_para_features(void)return r; } +static inline unsigned int kvm_arch_pv_features (void ) +{ +return 0 ; +} +#endif /* __KERNEL__ */ #endif /* __POWERPC_KVM_PARA_H__ */ arch/s390/include/asm/kvm_para.h +5
-0@@ -149,6 +149,11 @@ static inline unsigned int kvm_arch_para_features(void)return 0 ; } +static inline unsigned int kvm_arch_pv_features (void ) +{ +return 0 ; +} +#endif #endif /* __S390_KVM_PARA_H */ arch/x86/include/asm/kvm_para.h +7
-0@@ -208,6 +208,13 @@ static inline void kvm_disable_steal_time(void) }#endif +#ifdef KVM_PV_PORT +static inline unsigned int kvm_arch_pv_features (void ) +{ +return inl (KVM_PV_PORT ); +} +#endif +#endif /* __KERNEL__ */ #endif /* _ASM_X86_KVM_PARA_H */ arch/x86/kernel/kvm.c +14
-0@@ -335,6 +335,17 @@ static struct notifier_block kvm_pv_reboot_nb = { .notifier_call = kvm_pv_reboot_notify, }; +static int +kvm_pv_panic_notify (struct notifier_block *nb,unsigned long code,void *unused) +{ +outl (KVM_PV_PANICKED ,KVM_PV_PORT ); +return NOTIFY_DONE ; +} + +static struct notifier_block kvm_pv_panic_nb = { + .notifier_call = kvm_pv_panic_notify, +}; +static u64 kvm_steal_clock (int cpu) {u64 steal;@@ -421,6 +432,9 @@ void __init kvm_guest_init(void)paravirt_ops_setup ();register_reboot_notifier (&kvm_pv_reboot_nb); +if (kvm_pv_has_feature (KVM_PV_FEATURE_PANICKED )) +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 ))include/linux/kvm_para.h +15
-0@@ -20,6 +20,14 @@#define KVM_HC_FEATURES 3#define KVM_HC_PPC_MAP_MAGIC_PAGE 4 +#define KVM_PV_PORT (0x505UL) + +/* The bit of the value read from KVM_PV_PORT */ +#define KVM_PV_FEATURE_PANICKED 0 + +/* The value writen to KVM_PV_PORT */ +#define KVM_PV_PANICKED 1 +/* * hypercalls use architecture specific */ @@ -33,5 +41,12 @@ static inline int kvm_para_has_feature(unsigned int feature)return 1 ;return 0 ; } + +static inline int kvm_pv_has_feature (unsigned int feature) +{ +if (kvm_arch_pv_features () & (1UL << feature)) +return 1 ; +return 0 ; +}#endif /* __KERNEL__ */ #endif /* __LINUX_KVM_PARA_H */
Quoted 10 lines
Quoted 10 lines
We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when startint the kernel
Havent looked deeply into that, butz wouldnt kvm_hypercall0 also fulfill all of these points? You just have to define the number for each architecture and then it should be possible to write a simple panic driver that works on all architectures.
Quoted 8 lines
include/linux/kvm_para.h line 24
Quoted 8 lines
include/linux/kvm_para.h +2
-0@@ -20,6 +20,14 @@#define KVM_HC_FEATURES 3#define KVM_HC_PPC_MAP_MAGIC_PAGE 4 +#define KVM_PV_PORT (0x505UL) +
ignoring the above, shouldnt a port number go into an architecture specific file?
Christian
At 06/12/2012 03:49 PM, Christian Borntraeger Wrote:
Quoted 11 lines
Quoted 10 lines
Quoted 10 lines
We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when startint the kernel
Quoted 3 lines
Havent looked deeply into that, butz wouldnt
kvm_hypercall0also fulfill all of these points? You just have to define the number for each architecture and then it should be possible to write a simple panic driver that works on all architectures.
kvm_hypercall0? Avi said that we should avoid touching hypercall.
Thanks
Wen Congyang
Quoted 16 lines
Quoted 9 lines
include/linux/kvm_para.h line 24
Quoted 9 lines
include/linux/kvm_para.h +2
-0@@ -20,6 +20,14 @@#define KVM_HC_FEATURES 3#define KVM_HC_PPC_MAP_MAGIC_PAGE 4 +#define KVM_PV_PORT (0x505UL) +ignoring the above, shouldnt a port number go into an architecture specific file?
Christian
At 06/12/2012 03:49 PM, Christian Borntraeger Wrote:
Quoted 21 lines
Quoted 10 lines
Quoted 10 lines
We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when startint the kernelHavent looked deeply into that, butz wouldnt
kvm_hypercall0also fulfill all of these points? You just have to define the number for each architecture and then it should be possible to write a simple panic driver that works on all architectures.Quoted 6 lines
Quoted 6 lines
include/linux/kvm_para.h +0
-0@@ -20,6 +20,14 @@#define KVM_HC_FEATURES 3#define KVM_HC_PPC_MAP_MAGIC_PAGE 4
Quoted 4 lines
Quoted 2 lines
include/linux/kvm_para.h line 24
Quoted 2 lines
include/linux/kvm_para.h +2
-0+#define KVM_PV_PORT (0x505UL) +ignoring the above, shouldnt a port number go into an architecture specific file?
I am not sure whether it should be put into an architecture specific file.
Thanks
Wen Congyang
Quoted 10 lines
Christian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 22 lines · Wen Congyang
At 06/12/2012 03:49 PM, Christian Borntraeger Wrote:
Quoted 21 lines
Quoted 10 lines
Quoted 10 lines
We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.We have decided to avoid touching hypervisor. The reason why I choose choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when startint the kernelHavent looked deeply into that, butz wouldnt
kvm_hypercall0also fulfill all of these points? You just have to define the number for each architecture and then it should be possible to write a simple panic driver that works on all architectures.Quoted 6 lines
Quoted 6 lines
include/linux/kvm_para.h +0
-0@@ -20,6 +20,14 @@#define KVM_HC_FEATURES 3#define KVM_HC_PPC_MAP_MAGIC_PAGE 4
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
include/linux/kvm_para.h line 24
Quoted 2 lines
include/linux/kvm_para.h +2
-0+#define KVM_PV_PORT (0x505UL) +ignoring the above, shouldnt a port number go into an architecture specific file?
I am not sure whether it should be put into an architecture specific file.
Because PIO is x86 thing.
--
Gleb.