Patchwork [v8] kvm: notify host when the guest is panicked

login
register
mail settings
Submitter Wen Congyang
Date Aug. 8, 2012, 2:43 a.m.
Message ID <5021D235.4050800@cn.fujitsu.com>
Download mbox | patch
Permalink /patch/175840/
State New
Headers show

Comments

Wen Congyang - Aug. 8, 2012, 2:43 a.m.
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 starting the kernel

Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
---
 Documentation/virtual/kvm/pv_event.txt |   32 ++++++++++++++++++++++++++++++++
 arch/ia64/include/asm/kvm_para.h       |   14 ++++++++++++++
 arch/powerpc/include/asm/kvm_para.h    |   14 ++++++++++++++
 arch/s390/include/asm/kvm_para.h       |   14 ++++++++++++++
 arch/x86/include/asm/kvm_para.h        |   27 +++++++++++++++++++++++++++
 arch/x86/kernel/kvm.c                  |   25 +++++++++++++++++++++++++
 include/linux/kvm_para.h               |   23 +++++++++++++++++++++++
 7 files changed, 149 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/virtual/kvm/pv_event.txt
Andrew Jones - Aug. 8, 2012, 9:12 a.m.
On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
> diff --git a/Documentation/virtual/kvm/pv_event.txt b/Documentation/virtual/kvm/pv_event.txt
> new file mode 100644
> index 0000000..0ebc890
> --- /dev/null
> +++ b/Documentation/virtual/kvm/pv_event.txt
> @@ -0,0 +1,32 @@
> +The KVM paravirtual event interface
> +=================================
> +
> +Initializing the paravirtual event interface
> +======================
> +kvm_pv_event_init()
> +Argiments:
> +	None
> +
> +Return Value:
> +	0 : The guest kernel can't use paravirtual event interface.
> +	-1: The guest kernel can use paravirtual event interface.
> +

This documentation has the can and can't backwards.
Wen Congyang - Aug. 8, 2012, 9:28 a.m.
At 08/08/2012 05:12 PM, Andrew Jones Wrote:
> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
>> diff --git a/Documentation/virtual/kvm/pv_event.txt b/Documentation/virtual/kvm/pv_event.txt
>> new file mode 100644
>> index 0000000..0ebc890
>> --- /dev/null
>> +++ b/Documentation/virtual/kvm/pv_event.txt
>> @@ -0,0 +1,32 @@
>> +The KVM paravirtual event interface
>> +=================================
>> +
>> +Initializing the paravirtual event interface
>> +======================
>> +kvm_pv_event_init()
>> +Argiments:
>> +	None
>> +
>> +Return Value:
>> +	0 : The guest kernel can't use paravirtual event interface.
>> +	-1: The guest kernel can use paravirtual event interface.
>> +
> 
> This documentation has the can and can't backwards.
> 

Yes, I will fix it.

Thanks
Wen Congyang
Marcelo Tosatti - Aug. 13, 2012, 6:21 p.m.
On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
> 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 starting the kernel

How about searching for the "Kernel panic - not syncing" string 
in the guests serial output? Say libvirtd could take an action upon
that?

Advantages:
- It works for all architectures.
- It does not depend on any virtual device.
- It works as early as serial console output does (panics before
that should be rare).
- It allows you to see why the guest panicked.

> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> ---
>  Documentation/virtual/kvm/pv_event.txt |   32 ++++++++++++++++++++++++++++++++
>  arch/ia64/include/asm/kvm_para.h       |   14 ++++++++++++++
>  arch/powerpc/include/asm/kvm_para.h    |   14 ++++++++++++++
>  arch/s390/include/asm/kvm_para.h       |   14 ++++++++++++++
>  arch/x86/include/asm/kvm_para.h        |   27 +++++++++++++++++++++++++++
>  arch/x86/kernel/kvm.c                  |   25 +++++++++++++++++++++++++
>  include/linux/kvm_para.h               |   23 +++++++++++++++++++++++
>  7 files changed, 149 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/virtual/kvm/pv_event.txt
> 
> diff --git a/Documentation/virtual/kvm/pv_event.txt b/Documentation/virtual/kvm/pv_event.txt
> new file mode 100644
> index 0000000..0ebc890
> --- /dev/null
> +++ b/Documentation/virtual/kvm/pv_event.txt
> @@ -0,0 +1,32 @@
> +The KVM paravirtual event interface
> +=================================
> +
> +Initializing the paravirtual event interface
> +======================
> +kvm_pv_event_init()
> +Argiments:
> +	None
> +
> +Return Value:
> +	0 : The guest kernel can't use paravirtual event interface.
> +	-1: The guest kernel can use paravirtual event interface.
> +
> +Querying whether the event can be ejected
> +======================
> +kvm_pv_has_feature()
> +Arguments:
> +	feature: The bit value of this paravirtual event to query
> +
> +Return Value:
> +	0: The guest kernel can't eject this paravirtual event.
> +	1: The guest kernel can eject this paravirtual event.
> +
> +
> +Ejecting paravirtual event
> +======================
> +kvm_pv_eject_event()
> +Arguments:
> +	event: The event to be ejected.
> +
> +Return Value:
> +	None
> diff --git a/arch/ia64/include/asm/kvm_para.h b/arch/ia64/include/asm/kvm_para.h
> index 2019cb9..b5ec658 100644
> --- a/arch/ia64/include/asm/kvm_para.h
> +++ b/arch/ia64/include/asm/kvm_para.h
> @@ -31,6 +31,20 @@ static inline bool kvm_check_and_clear_guest_paused(void)
>  	return false;
>  }
>  
> +static inline int kvm_arch_pv_event_init(void)
> +{
> +	return 0;
> +}
> +
> +static inline unsigned int kvm_arch_pv_features(void)
> +{
> +	return 0;
> +}
> +
> +static inline void kvm_arch_pv_eject_event(unsigned int event)
> +{
> +}
> +
>  #endif
>  
>  #endif
> diff --git a/arch/powerpc/include/asm/kvm_para.h b/arch/powerpc/include/asm/kvm_para.h
> index c18916b..01b98c7 100644
> --- a/arch/powerpc/include/asm/kvm_para.h
> +++ b/arch/powerpc/include/asm/kvm_para.h
> @@ -211,6 +211,20 @@ static inline bool kvm_check_and_clear_guest_paused(void)
>  	return false;
>  }
>  
> +static inline int kvm_arch_pv_event_init(void)
> +{
> +	return 0;
> +}
> +
> +static inline unsigned int kvm_arch_pv_features(void)
> +{
> +	return 0;
> +}
> +
> +static inline void kvm_arch_pv_eject_event(unsigned int event)
> +{
> +}
> +
>  #endif /* __KERNEL__ */
>  
>  #endif /* __POWERPC_KVM_PARA_H__ */
> diff --git a/arch/s390/include/asm/kvm_para.h b/arch/s390/include/asm/kvm_para.h
> index da44867..00ce058 100644
> --- a/arch/s390/include/asm/kvm_para.h
> +++ b/arch/s390/include/asm/kvm_para.h
> @@ -154,6 +154,20 @@ static inline bool kvm_check_and_clear_guest_paused(void)
>  	return false;
>  }
>  
> +static inline int kvm_arch_pv_event_init(void)
> +{
> +	return 0;
> +}
> +
> +static inline unsigned int kvm_arch_pv_features(void)
> +{
> +	return 0;
> +}
> +
> +static inline void kvm_arch_pv_eject_event(unsigned int event)
> +{
> +}
> +
>  #endif
>  
>  #endif /* __S390_KVM_PARA_H */
> diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> index 2f7712e..7d297f0 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -96,8 +96,11 @@ struct kvm_vcpu_pv_apf_data {
>  #define KVM_PV_EOI_ENABLED KVM_PV_EOI_MASK
>  #define KVM_PV_EOI_DISABLED 0x0
>  
> +#define KVM_PV_EVENT_PORT	(0x505UL)
> +
>  #ifdef __KERNEL__
>  #include <asm/processor.h>
> +#include <linux/ioport.h>
>  
>  extern void kvmclock_init(void);
>  extern int kvm_register_clock(char *txt);
> @@ -228,6 +231,30 @@ static inline void kvm_disable_steal_time(void)
>  }
>  #endif
>  
> +static inline int kvm_arch_pv_event_init(void)
> +{
> +	if (!request_region(KVM_PV_EVENT_PORT, 1, "KVM_PV_EVENT"))
> +		return -1;
> +
> +	return 0;
> +}
> +
> +static inline unsigned int kvm_arch_pv_features(void)
> +{
> +	unsigned int features = inl(KVM_PV_EVENT_PORT);
> +
> +	/* Reading from an invalid I/O port will return -1 */
> +	if (features == ~0)
> +		features = 0;
> +
> +	return features;
> +}
> +
> +static inline void kvm_arch_pv_eject_event(unsigned int event)
> +{
> +	outl(event, KVM_PV_EVENT_PORT);
> +}
> +
>  #endif /* __KERNEL__ */
>  
>  #endif /* _ASM_X86_KVM_PARA_H */
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index c1d61ee..6129459 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -368,6 +368,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_pv_eject_event(KVM_PV_EVENT_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;
> @@ -447,6 +458,20 @@ static void __init kvm_apf_trap_init(void)
>  	set_intr_gate(14, &async_page_fault);
>  }
>  
> +static void __init kvm_pv_panicked_event_init(void)
> +{
> +	if (!kvm_para_available())
> +		return;
> +
> +	if (kvm_pv_event_init())
> +		return;
> +
> +	if (kvm_pv_has_feature(KVM_PV_FEATURE_PANICKED))
> +		atomic_notifier_chain_register(&panic_notifier_list,
> +			&kvm_pv_panic_nb);
> +}
> +arch_initcall(kvm_pv_panicked_event_init);
> +
>  void __init kvm_guest_init(void)
>  {
>  	int i;
> diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
> index ff476dd..8e0fb81 100644
> --- a/include/linux/kvm_para.h
> +++ b/include/linux/kvm_para.h
> @@ -20,6 +20,12 @@
>  #define KVM_HC_FEATURES			3
>  #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
>  
> +/* The bit of supported pv event */
> +#define KVM_PV_FEATURE_PANICKED	0
> +
> +/* The pv event value */
> +#define KVM_PV_EVENT_PANICKED	1
> +
>  /*
>   * hypercalls use architecture specific
>   */
> @@ -33,5 +39,22 @@ static inline int kvm_para_has_feature(unsigned int feature)
>  		return 1;
>  	return 0;
>  }
> +
> +static inline int kvm_pv_event_init(void)
> +{
> +	return kvm_arch_pv_event_init();
> +}
> +
> +static inline int kvm_pv_has_feature(unsigned int feature)
> +{
> +	if (kvm_arch_pv_features() & (1UL << feature))
> +		return 1;
> +	return 0;
> +}
> +
> +static inline void kvm_pv_eject_event(unsigned int event)
> +{
> +	kvm_arch_pv_eject_event(event);
> +}
>  #endif /* __KERNEL__ */
>  #endif /* __LINUX_KVM_PARA_H */
> -- 
> 1.7.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Eric Blake - Aug. 13, 2012, 7:48 p.m.
On 08/13/2012 12:21 PM, Marcelo Tosatti wrote:
> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
>> 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 starting the kernel
> 
> How about searching for the "Kernel panic - not syncing" string 
> in the guests serial output? Say libvirtd could take an action upon
> that?
> 
> Advantages:
> - It works for all architectures.
> - It does not depend on any virtual device.

But it _does_ depend on a serial console, and furthermore requires
libvirt to tee the serial console (right now, libvirt can treat the
console as an opaque pass-through to the end user, but if you expect
libvirt to parse the serial console for a particular string, you've lost
some efficiency).

> - It works as early as serial console output does (panics before
> that should be rare).
> - It allows you to see why the guest panicked.

I think your arguments for a serial console have already been made and
refuted in earlier versions of this patch series, which is WHY this
series is still applicable.
Marcelo Tosatti - Aug. 13, 2012, 8:24 p.m.
On Mon, Aug 13, 2012 at 01:48:39PM -0600, Eric Blake wrote:
> On 08/13/2012 12:21 PM, Marcelo Tosatti wrote:
> > On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
> >> 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 starting the kernel
> > 
> > How about searching for the "Kernel panic - not syncing" string 
> > in the guests serial output? Say libvirtd could take an action upon
> > that?
> > 
> > Advantages:
> > - It works for all architectures.
> > - It does not depend on any virtual device.
> 
> But it _does_ depend on a serial console,

Which already exists and is supported.

>  and furthermore requires
> libvirt to tee the serial console (right now, libvirt can treat the
> console as an opaque pass-through to the end user, but if you expect
> libvirt to parse the serial console for a particular string, you've lost
> some efficiency).
> 
> > - It works as early as serial console output does (panics before
> > that should be rare).
> > - It allows you to see why the guest panicked.
> 
> I think your arguments for a serial console have already been made and
> refuted in earlier versions of this patch series, which is WHY this
> series is still applicable.

Refuted why, exactly? Efficiency to parse serial console output in
libvirt should not be a major issue surely?

Either way:

The device should be arch independent, as "panic" is not specific 
to a particular architecture. For example virtio which would also work
on S390.

Custom IO port == virtual device, so that depends on virtual
device already.
Gleb Natapov - Aug. 14, 2012, 7:47 a.m.
On Mon, Aug 13, 2012 at 05:24:52PM -0300, Marcelo Tosatti wrote:
> On Mon, Aug 13, 2012 at 01:48:39PM -0600, Eric Blake wrote:
> > On 08/13/2012 12:21 PM, Marcelo Tosatti wrote:
> > > On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
> > >> 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 starting the kernel
> > > 
> > > How about searching for the "Kernel panic - not syncing" string 
> > > in the guests serial output? Say libvirtd could take an action upon
> > > that?
> > > 
> > > Advantages:
> > > - It works for all architectures.
> > > - It does not depend on any virtual device.
> > 
> > But it _does_ depend on a serial console,
> 
> Which already exists and is supported.
> 
> >  and furthermore requires
> > libvirt to tee the serial console (right now, libvirt can treat the
> > console as an opaque pass-through to the end user, but if you expect
> > libvirt to parse the serial console for a particular string, you've lost
> > some efficiency).
> > 
> > > - It works as early as serial console output does (panics before
> > > that should be rare).
> > > - It allows you to see why the guest panicked.
> > 
> > I think your arguments for a serial console have already been made and
> > refuted in earlier versions of this patch series, which is WHY this
> > series is still applicable.
> 
> Refuted why, exactly? Efficiency to parse serial console output in
> libvirt should not be a major issue surely?
> 
It is not zero config (guests do not send console output to serial by
default). If vm users want to use serial for its working console panic
notification will trigger every time user examines dmesg with "Kernel
panic - not syncing" in it.

--
			Gleb.
Daniel P. Berrange - Aug. 14, 2012, 8:56 a.m.
On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
> > 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 starting the kernel
> 
> How about searching for the "Kernel panic - not syncing" string 
> in the guests serial output? Say libvirtd could take an action upon
> that?

No, this is not satisfactory. It depends on the guest OS being
configured to use the serial port for console output which we
cannot mandate, since it may well be required for other purposes.


Daniel
Jan Kiszka - Aug. 14, 2012, 10:42 a.m.
On 2012-08-14 10:56, Daniel P. Berrange wrote:
> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
>>> 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 starting the kernel
>>
>> How about searching for the "Kernel panic - not syncing" string 
>> in the guests serial output? Say libvirtd could take an action upon
>> that?
> 
> No, this is not satisfactory. It depends on the guest OS being
> configured to use the serial port for console output which we
> cannot mandate, since it may well be required for other purposes.

Well, we have more than a single serial port, even when leaving
virtio-serial aside...

Jan
Yan Vugenfirer - Aug. 14, 2012, 2:55 p.m.
On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:

> On 2012-08-14 10:56, Daniel P. Berrange wrote:
>> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
>>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
>>>> 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 starting the kernel
>>> 
>>> How about searching for the "Kernel panic - not syncing" string 
>>> in the guests serial output? Say libvirtd could take an action upon
>>> that?
>> 
>> No, this is not satisfactory. It depends on the guest OS being
>> configured to use the serial port for console output which we
>> cannot mandate, since it may well be required for other purposes.
> 
Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)

What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.

Yan. 


> Well, we have more than a single serial port, even when leaving
> virtio-serial aside...
> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
> Corporate Competence Center Embedded Linux
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Kiszka - Aug. 14, 2012, 3:01 p.m.
On 2012-08-14 16:55, Yan Vugenfirer wrote:
> 
> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
> 
>> On 2012-08-14 10:56, Daniel P. Berrange wrote:
>>> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
>>>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
>>>>> 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 starting the kernel
>>>>
>>>> How about searching for the "Kernel panic - not syncing" string 
>>>> in the guests serial output? Say libvirtd could take an action upon
>>>> that?
>>>
>>> No, this is not satisfactory. It depends on the guest OS being
>>> configured to use the serial port for console output which we
>>> cannot mandate, since it may well be required for other purposes.
>>
> Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)
> 
> What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.

What prevents writing the magic words to a second serial port in the
same way via that callback?

Jan
Marcelo Tosatti - Aug. 14, 2012, 3:29 p.m.
On Tue, Aug 14, 2012 at 10:47:48AM +0300, Gleb Natapov wrote:
> On Mon, Aug 13, 2012 at 05:24:52PM -0300, Marcelo Tosatti wrote:
> > On Mon, Aug 13, 2012 at 01:48:39PM -0600, Eric Blake wrote:
> > > On 08/13/2012 12:21 PM, Marcelo Tosatti wrote:
> > > > On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
> > > >> 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 starting the kernel
> > > > 
> > > > How about searching for the "Kernel panic - not syncing" string 
> > > > in the guests serial output? Say libvirtd could take an action upon
> > > > that?
> > > > 
> > > > Advantages:
> > > > - It works for all architectures.
> > > > - It does not depend on any virtual device.
> > > 
> > > But it _does_ depend on a serial console,
> > 
> > Which already exists and is supported.
> > 
> > >  and furthermore requires
> > > libvirt to tee the serial console (right now, libvirt can treat the
> > > console as an opaque pass-through to the end user, but if you expect
> > > libvirt to parse the serial console for a particular string, you've lost
> > > some efficiency).
> > > 
> > > > - It works as early as serial console output does (panics before
> > > > that should be rare).
> > > > - It allows you to see why the guest panicked.
> > > 
> > > I think your arguments for a serial console have already been made and
> > > refuted in earlier versions of this patch series, which is WHY this
> > > series is still applicable.
> > 
> > Refuted why, exactly? Efficiency to parse serial console output in
> > libvirt should not be a major issue surely?
> > 
> It is not zero config (guests do not send console output to serial by
> default). If vm users want to use serial for its working console panic
> notification will trigger every time user examines dmesg with "Kernel
> panic - not syncing" in it.

Ok, then it would have to be a dedicated serial console which starts
to become funny.

Use a simple virtio device, then, it starts early enough (or can be made
to) during kernel init for most relevant production panics, and works
for all architectures.
Marcelo Tosatti - Aug. 14, 2012, 3:42 p.m.
On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
> 
> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
> 
> > On 2012-08-14 10:56, Daniel P. Berrange wrote:
> >> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
> >>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
> >>>> 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 starting the kernel
> >>> 
> >>> How about searching for the "Kernel panic - not syncing" string 
> >>> in the guests serial output? Say libvirtd could take an action upon
> >>> that?
> >> 
> >> No, this is not satisfactory. It depends on the guest OS being
> >> configured to use the serial port for console output which we
> >> cannot mandate, since it may well be required for other purposes.
> > 
> Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)
> 
> What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.
> 
> Yan. 

Considering whether a "panic-device" should cover other OSes is also 
something to consider. Even for Linux, is "panic" the only case which
should be reported via the mechanism? What about oopses without panic? 

Is the mechanism general enough for supporting new events, etc.

> 
> > Well, we have more than a single serial port, even when leaving
> > virtio-serial aside...
> > 
> > Jan
> > 
> > -- 
> > Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
> > Corporate Competence Center Embedded Linux
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
Gleb Natapov - Aug. 14, 2012, 3:50 p.m.
On Tue, Aug 14, 2012 at 12:29:38PM -0300, Marcelo Tosatti wrote:
> On Tue, Aug 14, 2012 at 10:47:48AM +0300, Gleb Natapov wrote:
> > On Mon, Aug 13, 2012 at 05:24:52PM -0300, Marcelo Tosatti wrote:
> > > On Mon, Aug 13, 2012 at 01:48:39PM -0600, Eric Blake wrote:
> > > > On 08/13/2012 12:21 PM, Marcelo Tosatti wrote:
> > > > > On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
> > > > >> 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 starting the kernel
> > > > > 
> > > > > How about searching for the "Kernel panic - not syncing" string 
> > > > > in the guests serial output? Say libvirtd could take an action upon
> > > > > that?
> > > > > 
> > > > > Advantages:
> > > > > - It works for all architectures.
> > > > > - It does not depend on any virtual device.
> > > > 
> > > > But it _does_ depend on a serial console,
> > > 
> > > Which already exists and is supported.
> > > 
> > > >  and furthermore requires
> > > > libvirt to tee the serial console (right now, libvirt can treat the
> > > > console as an opaque pass-through to the end user, but if you expect
> > > > libvirt to parse the serial console for a particular string, you've lost
> > > > some efficiency).
> > > > 
> > > > > - It works as early as serial console output does (panics before
> > > > > that should be rare).
> > > > > - It allows you to see why the guest panicked.
> > > > 
> > > > I think your arguments for a serial console have already been made and
> > > > refuted in earlier versions of this patch series, which is WHY this
> > > > series is still applicable.
> > > 
> > > Refuted why, exactly? Efficiency to parse serial console output in
> > > libvirt should not be a major issue surely?
> > > 
> > It is not zero config (guests do not send console output to serial by
> > default). If vm users want to use serial for its working console panic
> > notification will trigger every time user examines dmesg with "Kernel
> > panic - not syncing" in it.
> 
> Ok, then it would have to be a dedicated serial console which starts
> to become funny.
> 
We do have support for many virtio-serial channels.

> Use a simple virtio device, then, it starts early enough (or can be made
> to) during kernel init for most relevant production panics, and works
> for all architectures.
The only downside of using dedicated virtio-serial channel that I can
see is that to catch early panic all of the virtio should be compiled
in.

--
			Gleb.
Anthony Liguori - Aug. 14, 2012, 6:53 p.m.
Marcelo Tosatti <mtosatti@redhat.com> writes:

> On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
>> 
>> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
>> 
>> > On 2012-08-14 10:56, Daniel P. Berrange wrote:
>> >> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
>> >>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
>> >>>> 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 starting the kernel
>> >>> 
>> >>> How about searching for the "Kernel panic - not syncing" string 
>> >>> in the guests serial output? Say libvirtd could take an action upon
>> >>> that?
>> >> 
>> >> No, this is not satisfactory. It depends on the guest OS being
>> >> configured to use the serial port for console output which we
>> >> cannot mandate, since it may well be required for other purposes.
>> > 
>> Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)
>> 
>> What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.
>> 
>> Yan. 
>
> Considering whether a "panic-device" should cover other OSes is also 
> something to consider. Even for Linux, is "panic" the only case which
> should be reported via the mechanism? What about oopses without panic? 
>
> Is the mechanism general enough for supporting new events, etc.

Hi,

I think this discussion is gone of the deep end.

Forget about !x86 platforms.  They have their own way to do this sort of
thing.  Think of this feature like a status LED on a motherboard.  These
are very common and usually controlled by IO ports.

We're simply reserving a "status LED" for the guest to indicate that it
has paniced.  Let's not over engineer this.

Regards,

Anthony Liguori

>
>> 
>> > Well, we have more than a single serial port, even when leaving
>> > virtio-serial aside...
>> > 
>> > Jan
>> > 
>> > -- 
>> > Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
>> > Corporate Competence Center Embedded Linux
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe kvm" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
Marcelo Tosatti - Aug. 14, 2012, 7:19 p.m.
On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
> Marcelo Tosatti <mtosatti@redhat.com> writes:
> 
> > On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
> >> 
> >> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
> >> 
> >> > On 2012-08-14 10:56, Daniel P. Berrange wrote:
> >> >> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
> >> >>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
> >> >>>> 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 starting the kernel
> >> >>> 
> >> >>> How about searching for the "Kernel panic - not syncing" string 
> >> >>> in the guests serial output? Say libvirtd could take an action upon
> >> >>> that?
> >> >> 
> >> >> No, this is not satisfactory. It depends on the guest OS being
> >> >> configured to use the serial port for console output which we
> >> >> cannot mandate, since it may well be required for other purposes.
> >> > 
> >> Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)
> >> 
> >> What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.
> >> 
> >> Yan. 
> >
> > Considering whether a "panic-device" should cover other OSes is also \

> > something to consider. Even for Linux, is "panic" the only case which
> > should be reported via the mechanism? What about oopses without panic? 
> >
> > Is the mechanism general enough for supporting new events, etc.
> 
> Hi,
> 
> I think this discussion is gone of the deep end.
> 
> Forget about !x86 platforms.  They have their own way to do this sort of
> thing.  

The panic function in kernel/panic.c has the following options, which
appear to be arch independent, on panic:

- reboot 
- blink

None are paravirtual interfaces however.

> Think of this feature like a status LED on a motherboard.  These
> are very common and usually controlled by IO ports.
> 
> We're simply reserving a "status LED" for the guest to indicate that it
> has paniced.  Let's not over engineer this.

My concern is that you end up with state that is dependant on x86.

Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED

Having the ability to stop/restart the guest (and even introducing a 
new VM runstate) is more than a status LED analogy.

Can this new infrastructure be used by other architectures?

Do you consider allowing support for Windows as overengineering?

> Regards,
> 
> Anthony Liguori
> 
> >
> >> 
> >> > Well, we have more than a single serial port, even when leaving
> >> > virtio-serial aside...
> >> > 
> >> > Jan
> >> > 
> >> > -- 
> >> > Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
> >> > Corporate Competence Center Embedded Linux
> >> > --
> >> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> >> > the body of a message to majordomo@vger.kernel.org
> >> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
Anthony Liguori - Aug. 14, 2012, 7:35 p.m.
Marcelo Tosatti <mtosatti@redhat.com> writes:

> On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
>> Marcelo Tosatti <mtosatti@redhat.com> writes:
>> 
>> > On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
>> >> 
>> >> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
>> >> 
>> >> > On 2012-08-14 10:56, Daniel P. Berrange wrote:
>> >> >> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
>> >> >>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
>> >> >>>> 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 starting the kernel
>> >> >>> 
>> >> >>> How about searching for the "Kernel panic - not syncing" string 
>> >> >>> in the guests serial output? Say libvirtd could take an action upon
>> >> >>> that?
>> >> >> 
>> >> >> No, this is not satisfactory. It depends on the guest OS being
>> >> >> configured to use the serial port for console output which we
>> >> >> cannot mandate, since it may well be required for other purposes.
>> >> > 
>> >> Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)
>> >> 
>> >> What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.
>> >> 
>> >> Yan. 
>> >
>> > Considering whether a "panic-device" should cover other OSes is also \
>
>> > something to consider. Even for Linux, is "panic" the only case which
>> > should be reported via the mechanism? What about oopses without panic? 
>> >
>> > Is the mechanism general enough for supporting new events, etc.
>> 
>> Hi,
>> 
>> I think this discussion is gone of the deep end.
>> 
>> Forget about !x86 platforms.  They have their own way to do this sort of
>> thing.  
>
> The panic function in kernel/panic.c has the following options, which
> appear to be arch independent, on panic:
>
> - reboot 
> - blink

Not sure the semantics of blink but that might be a good place for a
pvops hook.

>
> None are paravirtual interfaces however.
>
>> Think of this feature like a status LED on a motherboard.  These
>> are very common and usually controlled by IO ports.
>> 
>> We're simply reserving a "status LED" for the guest to indicate that it
>> has paniced.  Let's not over engineer this.
>
> My concern is that you end up with state that is dependant on x86.
>
> Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED
>
> Having the ability to stop/restart the guest (and even introducing a 
> new VM runstate) is more than a status LED analogy.

I must admit, I don't know why a new runstate is necessary/useful.  The
kernel shouldn't have to care about the difference between a halted guest
and a panicked guest.  That level of information belongs in userspace IMHO.

> Can this new infrastructure be used by other architectures?

I guess I don't understand why the kernel side of this isn't anything
more than a paravirt op hook that does a single outb() with the
remaining logic handled 100% in QEMU.

> Do you consider allowing support for Windows as overengineering?

I don't think there is a way to hook BSOD on Windows so attempting to
engineer something that works with Windows seems odd, no?

Regards,

Anthony Liguori

>
>> Regards,
>> 
>> Anthony Liguori
>> 
>> >
>> >> 
>> >> > Well, we have more than a single serial port, even when leaving
>> >> > virtio-serial aside...
>> >> > 
>> >> > Jan
>> >> > 
>> >> > -- 
>> >> > Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
>> >> > Corporate Competence Center Embedded Linux
>> >> > --
>> >> > To unsubscribe from this list: send the line "unsubscribe kvm" in
>> >> > the body of a message to majordomo@vger.kernel.org
>> >> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
Peter Maydell - Aug. 14, 2012, 7:58 p.m.
On 14 August 2012 19:53, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Forget about !x86 platforms.  They have their own way to do this sort of
> thing.  Think of this feature like a status LED on a motherboard.  These
> are very common and usually controlled by IO ports.

Please don't forget !x86 platforms, we are cute and loveable really :-)

> We're simply reserving a "status LED" for the guest to indicate that it
> has paniced.  Let's not over engineer this.

...not that QEMU actually has any kind of "front panel lights and switches"
interface at all, it might be nice to have one. I bet a lot of the embedded
boards have function DIP switches, heartbeat LEDs, etc etc...

-- PMM
Marcelo Tosatti - Aug. 14, 2012, 8:53 p.m.
On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
> Marcelo Tosatti <mtosatti@redhat.com> writes:
> 
> > On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
> >> Marcelo Tosatti <mtosatti@redhat.com> writes:
> >> 
> >> > On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
> >> >> 
> >> >> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
> >> >> 
> >> >> > On 2012-08-14 10:56, Daniel P. Berrange wrote:
> >> >> >> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
> >> >> >>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
> >> >> >>>> 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 starting the kernel
> >> >> >>> 
> >> >> >>> How about searching for the "Kernel panic - not syncing" string 
> >> >> >>> in the guests serial output? Say libvirtd could take an action upon
> >> >> >>> that?
> >> >> >> 
> >> >> >> No, this is not satisfactory. It depends on the guest OS being
> >> >> >> configured to use the serial port for console output which we
> >> >> >> cannot mandate, since it may well be required for other purposes.
> >> >> > 
> >> >> Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)
> >> >> 
> >> >> What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.
> >> >> 
> >> >> Yan. 
> >> >
> >> > Considering whether a "panic-device" should cover other OSes is also \
> >
> >> > something to consider. Even for Linux, is "panic" the only case which
> >> > should be reported via the mechanism? What about oopses without panic? 
> >> >
> >> > Is the mechanism general enough for supporting new events, etc.
> >> 
> >> Hi,
> >> 
> >> I think this discussion is gone of the deep end.
> >> 
> >> Forget about !x86 platforms.  They have their own way to do this sort of
> >> thing.  
> >
> > The panic function in kernel/panic.c has the following options, which
> > appear to be arch independent, on panic:
> >
> > - reboot 
> > - blink
> 
> Not sure the semantics of blink but that might be a good place for a
> pvops hook.
> 
> >
> > None are paravirtual interfaces however.
> >
> >> Think of this feature like a status LED on a motherboard.  These
> >> are very common and usually controlled by IO ports.
> >> 
> >> We're simply reserving a "status LED" for the guest to indicate that it
> >> has paniced.  Let's not over engineer this.
> >
> > My concern is that you end up with state that is dependant on x86.
> >
> > Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED
> >
> > Having the ability to stop/restart the guest (and even introducing a 
> > new VM runstate) is more than a status LED analogy.
> 
> I must admit, I don't know why a new runstate is necessary/useful.  The
> kernel shouldn't have to care about the difference between a halted guest
> and a panicked guest.  That level of information belongs in userspace IMHO.
> 
> > Can this new infrastructure be used by other architectures?
> 
> I guess I don't understand why the kernel side of this isn't anything
> more than a paravirt op hook that does a single outb() with the
> remaining logic handled 100% in QEMU.

From the patch description:

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

Wen, auto dump means dump of guest memory?

In that case, the notification should obviously stop the guest 
otherwise the guest might be reset by the time memdump from QEMU 
monitor runs.

But kexec supports dumping of memory already (i suppose it can 
do automatic dump+{reboot,shutdown}).

> > Do you consider allowing support for Windows as overengineering?
> 
> I don't think there is a way to hook BSOD on Windows so attempting to
> engineer something that works with Windows seems odd, no?

Unsure about hooking at BSOD time. But Windows has configurable 
memory dump/reset/reboot, so yes it should not necessary.

> 
> Regards,
> 
> Anthony Liguori
> 
> >
> >> Regards,
> >> 
> >> Anthony Liguori
> >> 
> >> >
> >> >> 
> >> >> > Well, we have more than a single serial port, even when leaving
> >> >> > virtio-serial aside...
> >> >> > 
> >> >> > Jan
> >> >> > 
> >> >> > -- 
> >> >> > Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
> >> >> > Corporate Competence Center Embedded Linux
> >> >> > --
> >> >> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> >> >> > the body of a message to majordomo@vger.kernel.org
> >> >> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Anthony Liguori - Aug. 14, 2012, 10:59 p.m.
Marcelo Tosatti <mtosatti@redhat.com> writes:

> On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
>> Marcelo Tosatti <mtosatti@redhat.com> writes:
>> 
>> > On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
>> >> Marcelo Tosatti <mtosatti@redhat.com> writes:
>> >> 
>> >> > On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
>> >> >> 
>> >> >> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
>> >> >> 
>> >> >> > On 2012-08-14 10:56, Daniel P. Berrange wrote:
>> >> >> >> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
>> >> >> >>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
>> >> >> >>>> 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 starting the kernel
>> >> >> >>> 
>> >> >> >>> How about searching for the "Kernel panic - not syncing" string 
>> >> >> >>> in the guests serial output? Say libvirtd could take an action upon
>> >> >> >>> that?
>> >> >> >> 
>> >> >> >> No, this is not satisfactory. It depends on the guest OS being
>> >> >> >> configured to use the serial port for console output which we
>> >> >> >> cannot mandate, since it may well be required for other purposes.
>> >> >> > 
>> >> >> Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)
>> >> >> 
>> >> >> What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.
>> >> >> 
>> >> >> Yan. 
>> >> >
>> >> > Considering whether a "panic-device" should cover other OSes is also \
>> >
>> >> > something to consider. Even for Linux, is "panic" the only case which
>> >> > should be reported via the mechanism? What about oopses without panic? 
>> >> >
>> >> > Is the mechanism general enough for supporting new events, etc.
>> >> 
>> >> Hi,
>> >> 
>> >> I think this discussion is gone of the deep end.
>> >> 
>> >> Forget about !x86 platforms.  They have their own way to do this sort of
>> >> thing.  
>> >
>> > The panic function in kernel/panic.c has the following options, which
>> > appear to be arch independent, on panic:
>> >
>> > - reboot 
>> > - blink
>> 
>> Not sure the semantics of blink but that might be a good place for a
>> pvops hook.
>> 
>> >
>> > None are paravirtual interfaces however.
>> >
>> >> Think of this feature like a status LED on a motherboard.  These
>> >> are very common and usually controlled by IO ports.
>> >> 
>> >> We're simply reserving a "status LED" for the guest to indicate that it
>> >> has paniced.  Let's not over engineer this.
>> >
>> > My concern is that you end up with state that is dependant on x86.
>> >
>> > Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED
>> >
>> > Having the ability to stop/restart the guest (and even introducing a 
>> > new VM runstate) is more than a status LED analogy.
>> 
>> I must admit, I don't know why a new runstate is necessary/useful.  The
>> kernel shouldn't have to care about the difference between a halted guest
>> and a panicked guest.  That level of information belongs in userspace IMHO.
>> 
>> > Can this new infrastructure be used by other architectures?
>> 
>> I guess I don't understand why the kernel side of this isn't anything
>> more than a paravirt op hook that does a single outb() with the
>> remaining logic handled 100% in QEMU.
>
> From the patch description:
>
> "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."

Why does this mandated another runstate?  QEMU can simply mark the VCPUs
as stopped and raise a QMP event.  The kernel doesn't care if the VCPUs
are stopped or panicked.

> Wen, auto dump means dump of guest memory?
>
> In that case, the notification should obviously stop the guest 
> otherwise the guest might be reset by the time memdump from QEMU 
> monitor runs.
>
> But kexec supports dumping of memory already (i suppose it can 
> do automatic dump+{reboot,shutdown}).
>
>> > Do you consider allowing support for Windows as overengineering?
>> 
>> I don't think there is a way to hook BSOD on Windows so attempting to
>> engineer something that works with Windows seems odd, no?
>
> Unsure about hooking at BSOD time. But Windows has configurable 
> memory dump/reset/reboot, so yes it should not necessary.

Do you mean it's not necessary to hook BSOD?

I've very often gotten asked: We know 1 person is experiencing this
crash condition, can we figure out from the host how many other VMs are
experiencing this crash too instead of waiting for a user to complain?

That's the primary use-case for this notification IMHO.  Just a simple
status LED from the guest to indicate that it's in a bad state.

Regards,

Anthony Liguori

>
>> 
>> Regards,
>> 
>> Anthony Liguori
>> 
>> >
>> >> Regards,
>> >> 
>> >> Anthony Liguori
>> >> 
>> >> >
>> >> >> 
>> >> >> > Well, we have more than a single serial port, even when leaving
>> >> >> > virtio-serial aside...
>> >> >> > 
>> >> >> > Jan
>> >> >> > 
>> >> >> > -- 
>> >> >> > Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
>> >> >> > Corporate Competence Center Embedded Linux
>> >> >> > --
>> >> >> > To unsubscribe from this list: send the line "unsubscribe kvm" in
>> >> >> > the body of a message to majordomo@vger.kernel.org
>> >> >> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Marcelo Tosatti - Aug. 15, 2012, 12:25 a.m.
On Tue, Aug 14, 2012 at 05:59:06PM -0500, Anthony Liguori wrote:
> Marcelo Tosatti <mtosatti@redhat.com> writes:
> 
> > On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
> >> Marcelo Tosatti <mtosatti@redhat.com> writes:
> >> 
> >> > On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
> >> >> Marcelo Tosatti <mtosatti@redhat.com> writes:
> >> >> 
> >> >> > On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
> >> >> >> 
> >> >> >> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
> >> >> >> 
> >> >> >> > On 2012-08-14 10:56, Daniel P. Berrange wrote:
> >> >> >> >> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
> >> >> >> >>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
> >> >> >> >>>> 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 starting the kernel
> >> >> >> >>> 
> >> >> >> >>> How about searching for the "Kernel panic - not syncing" string 
> >> >> >> >>> in the guests serial output? Say libvirtd could take an action upon
> >> >> >> >>> that?
> >> >> >> >> 
> >> >> >> >> No, this is not satisfactory. It depends on the guest OS being
> >> >> >> >> configured to use the serial port for console output which we
> >> >> >> >> cannot mandate, since it may well be required for other purposes.
> >> >> >> > 
> >> >> >> Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)
> >> >> >> 
> >> >> >> What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.
> >> >> >> 
> >> >> >> Yan. 
> >> >> >
> >> >> > Considering whether a "panic-device" should cover other OSes is also \
> >> >
> >> >> > something to consider. Even for Linux, is "panic" the only case which
> >> >> > should be reported via the mechanism? What about oopses without panic? 
> >> >> >
> >> >> > Is the mechanism general enough for supporting new events, etc.
> >> >> 
> >> >> Hi,
> >> >> 
> >> >> I think this discussion is gone of the deep end.
> >> >> 
> >> >> Forget about !x86 platforms.  They have their own way to do this sort of
> >> >> thing.  
> >> >
> >> > The panic function in kernel/panic.c has the following options, which
> >> > appear to be arch independent, on panic:
> >> >
> >> > - reboot 
> >> > - blink
> >> 
> >> Not sure the semantics of blink but that might be a good place for a
> >> pvops hook.
> >> 
> >> >
> >> > None are paravirtual interfaces however.
> >> >
> >> >> Think of this feature like a status LED on a motherboard.  These
> >> >> are very common and usually controlled by IO ports.
> >> >> 
> >> >> We're simply reserving a "status LED" for the guest to indicate that it
> >> >> has paniced.  Let's not over engineer this.
> >> >
> >> > My concern is that you end up with state that is dependant on x86.
> >> >
> >> > Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED
> >> >
> >> > Having the ability to stop/restart the guest (and even introducing a 
> >> > new VM runstate) is more than a status LED analogy.
> >> 
> >> I must admit, I don't know why a new runstate is necessary/useful.  The
> >> kernel shouldn't have to care about the difference between a halted guest
> >> and a panicked guest.  That level of information belongs in userspace IMHO.
> >> 
> >> > Can this new infrastructure be used by other architectures?
> >> 
> >> I guess I don't understand why the kernel side of this isn't anything
> >> more than a paravirt op hook that does a single outb() with the
> >> remaining logic handled 100% in QEMU.
> >
> > From the patch description:
> >
> > "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."
> 
> Why does this mandated another runstate?  

Good question.

> QEMU can simply mark the VCPUs as stopped and raise a QMP event.

Yes. As long as management app is able to find out for what the reason
the VM has been stopped (that is, its not an issue to lose the QMP
event).

> The kernel doesn't care if the VCPUs
> are stopped or panicked.
> > Wen, auto dump means dump of guest memory?
> >
> > In that case, the notification should obviously stop the guest 
> > otherwise the guest might be reset by the time memdump from QEMU 
> > monitor runs.
> >
> > But kexec supports dumping of memory already (i suppose it can 
> > do automatic dump+{reboot,shutdown}).
> >
> >> > Do you consider allowing support for Windows as overengineering?
> >> 
> >> I don't think there is a way to hook BSOD on Windows so attempting to
> >> engineer something that works with Windows seems odd, no?
> >
> > Unsure about hooking at BSOD time. But Windows has configurable 
> > memory dump/reset/reboot, so yes it should not necessary.
> 
> Do you mean it's not necessary to hook BSOD?

If all you need is dumping memory and rebooting the guest, then Windows
can do that automatically. Linux probably does, if not its possible 
to make it do so.

> I've very often gotten asked: We know 1 person is experiencing this
> crash condition, can we figure out from the host how many other VMs are
> experiencing this crash too instead of waiting for a user to complain?
> 
> That's the primary use-case for this notification IMHO.  Just a simple
> status LED from the guest to indicate that it's in a bad state.

That makes sense. But it appears to me that using an interface which is
not specific to x86 is interesting, so as to not require another
driver and matching QEMU code for other architectures. That is, 
for the "paravirtual status-LED-on-panic", there is no advantage 
in making every architecture different.

Also configuration of reboot-on-panic should override
panic-via-hypervisor (guest settings have priority over
panic-via-hypervisor).

For the usecase above (recording a critical event), it also makes sense
to support Windows.


> Regards,
> 
> Anthony Liguori
> 
> >
> >> 
> >> Regards,
> >> 
> >> Anthony Liguori
> >> 
> >> >
> >> >> Regards,
> >> >> 
> >> >> Anthony Liguori
> >> >> 
> >> >> >
> >> >> >> 
> >> >> >> > Well, we have more than a single serial port, even when leaving
> >> >> >> > virtio-serial aside...
> >> >> >> > 
> >> >> >> > Jan
> >> >> >> > 
> >> >> >> > -- 
> >> >> >> > Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
> >> >> >> > Corporate Competence Center Embedded Linux
> >> >> >> > --
> >> >> >> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> >> >> >> > the body of a message to majordomo@vger.kernel.org
> >> >> >> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe kvm" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Gleb Natapov - Aug. 15, 2012, 9:56 a.m.
On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
> > Do you consider allowing support for Windows as overengineering?
> 
> I don't think there is a way to hook BSOD on Windows so attempting to
> engineer something that works with Windows seems odd, no?
> 
Yan says in other email that is is possible to register a bugcheck callback.

--
			Gleb.
Yan Vugenfirer - Aug. 15, 2012, 11:38 a.m.
On Aug 14, 2012, at 10:35 PM, Anthony Liguori wrote:

> Marcelo Tosatti <mtosatti@redhat.com> writes:
> 
>> On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
>>> Marcelo Tosatti <mtosatti@redhat.com> writes:
>>> 
>>>> On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
>>>>> 
>>>>> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
>>>>> 
>>>>>> On 2012-08-14 10:56, Daniel P. Berrange wrote:
>>>>>>> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
>>>>>>>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
>>>>>>>>> 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 starting the kernel
>>>>>>>> 
>>>>>>>> How about searching for the "Kernel panic - not syncing" string 
>>>>>>>> in the guests serial output? Say libvirtd could take an action upon
>>>>>>>> that?
>>>>>>> 
>>>>>>> No, this is not satisfactory. It depends on the guest OS being
>>>>>>> configured to use the serial port for console output which we
>>>>>>> cannot mandate, since it may well be required for other purposes.
>>>>>> 
>>>>> Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)
>>>>> 
>>>>> What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.
>>>>> 
>>>>> Yan. 
>>>> 
>>>> Considering whether a "panic-device" should cover other OSes is also \
>> 
>>>> something to consider. Even for Linux, is "panic" the only case which
>>>> should be reported via the mechanism? What about oopses without panic? 
>>>> 
>>>> Is the mechanism general enough for supporting new events, etc.
>>> 
>>> Hi,
>>> 
>>> I think this discussion is gone of the deep end.
>>> 
>>> Forget about !x86 platforms.  They have their own way to do this sort of
>>> thing.  
>> 
>> The panic function in kernel/panic.c has the following options, which
>> appear to be arch independent, on panic:
>> 
>> - reboot 
>> - blink
> 
> Not sure the semantics of blink but that might be a good place for a
> pvops hook.
> 
>> 
>> None are paravirtual interfaces however.
>> 
>>> Think of this feature like a status LED on a motherboard.  These
>>> are very common and usually controlled by IO ports.
>>> 
>>> We're simply reserving a "status LED" for the guest to indicate that it
>>> has paniced.  Let's not over engineer this.
>> 
>> My concern is that you end up with state that is dependant on x86.
>> 
>> Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED
>> 
>> Having the ability to stop/restart the guest (and even introducing a 
>> new VM runstate) is more than a status LED analogy.
> 
> I must admit, I don't know why a new runstate is necessary/useful.  The
> kernel shouldn't have to care about the difference between a halted guest
> and a panicked guest.  That level of information belongs in userspace IMHO.
> 
>> Can this new infrastructure be used by other architectures?
> 
> I guess I don't understand why the kernel side of this isn't anything
> more than a paravirt op hook that does a single outb() with the
> remaining logic handled 100% in QEMU.
> 
>> Do you consider allowing support for Windows as overengineering?
> 
> I don't think there is a way to hook BSOD on Windows so attempting to
> engineer something that works with Windows seems odd, no?
> 

Actually there is a way (http://msdn.microsoft.com/en-us/library/windows/hardware/ff553105(v=vs.85).aspx). That's what I just mentioned already done in Windows virtio-net driver. 


Best regards,
Yan.

> Regards,
> 
> Anthony Liguori
> 
>> 
>>> Regards,
>>> 
>>> Anthony Liguori
>>> 
>>>> 
>>>>> 
>>>>>> Well, we have more than a single serial port, even when leaving
>>>>>> virtio-serial aside...
>>>>>> 
>>>>>> Jan
>>>>>> 
>>>>>> -- 
>>>>>> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
>>>>>> Corporate Competence Center Embedded Linux
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Yan Vugenfirer - Aug. 15, 2012, 11:42 a.m.
On Aug 15, 2012, at 12:56 PM, Gleb Natapov wrote:

> On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
>>> Do you consider allowing support for Windows as overengineering?
>> 
>> I don't think there is a way to hook BSOD on Windows so attempting to
>> engineer something that works with Windows seems odd, no?
>> 
> Yan says in other email that is is possible to register a bugcheck callback.
> 

Here you go - http://msdn.microsoft.com/en-us/library/windows/hardware/ff553105(v=vs.85).aspx
Already done in virtio-net for two reasons: 1. we could configure virtio-net to notify QEMU in a hacky way (write 1 to VIRTIO_PCI_ISR register) that there was a bugckeck .It was very useful debugging complex WHQL issues that involved host networking. 2. Store additional information (for example time stamps of last receive packet, last interrupt and etc) in crash dump.

Yan.

> --
> 			Gleb.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Wen Congyang - Aug. 22, 2012, 6:33 a.m.
At 08/15/2012 04:53 AM, Marcelo Tosatti Wrote:
> On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
>> Marcelo Tosatti <mtosatti@redhat.com> writes:
>>
>>> On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
>>>> Marcelo Tosatti <mtosatti@redhat.com> writes:
>>>>
>>>>> On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
>>>>>>
>>>>>> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
>>>>>>
>>>>>>> On 2012-08-14 10:56, Daniel P. Berrange wrote:
>>>>>>>> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
>>>>>>>>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
>>>>>>>>>> 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 starting the kernel
>>>>>>>>>
>>>>>>>>> How about searching for the "Kernel panic - not syncing" string 
>>>>>>>>> in the guests serial output? Say libvirtd could take an action upon
>>>>>>>>> that?
>>>>>>>>
>>>>>>>> No, this is not satisfactory. It depends on the guest OS being
>>>>>>>> configured to use the serial port for console output which we
>>>>>>>> cannot mandate, since it may well be required for other purposes.
>>>>>>>
>>>>>> Please don't forget Windows guests, there is no console and no "Kernel Panic" string ;)
>>>>>>
>>>>>> What I used for debugging purposes on Windows guest is to register a bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.
>>>>>>
>>>>>> Yan. 
>>>>>
>>>>> Considering whether a "panic-device" should cover other OSes is also \
>>>
>>>>> something to consider. Even for Linux, is "panic" the only case which
>>>>> should be reported via the mechanism? What about oopses without panic? 
>>>>>
>>>>> Is the mechanism general enough for supporting new events, etc.
>>>>
>>>> Hi,
>>>>
>>>> I think this discussion is gone of the deep end.
>>>>
>>>> Forget about !x86 platforms.  They have their own way to do this sort of
>>>> thing.  
>>>
>>> The panic function in kernel/panic.c has the following options, which
>>> appear to be arch independent, on panic:
>>>
>>> - reboot 
>>> - blink
>>
>> Not sure the semantics of blink but that might be a good place for a
>> pvops hook.
>>
>>>
>>> None are paravirtual interfaces however.
>>>
>>>> Think of this feature like a status LED on a motherboard.  These
>>>> are very common and usually controlled by IO ports.
>>>>
>>>> We're simply reserving a "status LED" for the guest to indicate that it
>>>> has paniced.  Let's not over engineer this.
>>>
>>> My concern is that you end up with state that is dependant on x86.
>>>
>>> Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED
>>>
>>> Having the ability to stop/restart the guest (and even introducing a 
>>> new VM runstate) is more than a status LED analogy.
>>
>> I must admit, I don't know why a new runstate is necessary/useful.  The
>> kernel shouldn't have to care about the difference between a halted guest
>> and a panicked guest.  That level of information belongs in userspace IMHO.
>>
>>> Can this new infrastructure be used by other architectures?
>>
>> I guess I don't understand why the kernel side of this isn't anything
>> more than a paravirt op hook that does a single outb() with the
>> remaining logic handled 100% in QEMU.
> 
>>From the patch description:
> 
> "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."
> 
> Wen, auto dump means dump of guest memory?

Yes.

> 
> In that case, the notification should obviously stop the guest 
> otherwise the guest might be reset by the time memdump from QEMU 
> monitor runs.

Yes, the guest is stopped while auto dumping.

> 
> But kexec supports dumping of memory already (i suppose it can 
> do automatic dump+{reboot,shutdown}).

It can be easily done in management app.

Thanks
Wen Congyang

> 
>>> Do you consider allowing support for Windows as overengineering?
>>
>> I don't think there is a way to hook BSOD on Windows so attempting to
>> engineer something that works with Windows seems odd, no?
> 
> Unsure about hooking at BSOD time. But Windows has configurable 
> memory dump/reset/reboot, so yes it should not necessary.
> 
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>>
>>>> Regards,
>>>>
>>>> Anthony Liguori
>>>>
>>>>>
>>>>>>
>>>>>>> Well, we have more than a single serial port, even when leaving
>>>>>>> virtio-serial aside...
>>>>>>>
>>>>>>> Jan
>>>>>>>
>>>>>>> -- 
>>>>>>> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
>>>>>>> Corporate Competence Center Embedded Linux
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> 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/
>

Patch

diff --git a/Documentation/virtual/kvm/pv_event.txt b/Documentation/virtual/kvm/pv_event.txt
new file mode 100644
index 0000000..0ebc890
--- /dev/null
+++ b/Documentation/virtual/kvm/pv_event.txt
@@ -0,0 +1,32 @@ 
+The KVM paravirtual event interface
+=================================
+
+Initializing the paravirtual event interface
+======================
+kvm_pv_event_init()
+Argiments:
+	None
+
+Return Value:
+	0 : The guest kernel can't use paravirtual event interface.
+	-1: The guest kernel can use paravirtual event interface.
+
+Querying whether the event can be ejected
+======================
+kvm_pv_has_feature()
+Arguments:
+	feature: The bit value of this paravirtual event to query
+
+Return Value:
+	0: The guest kernel can't eject this paravirtual event.
+	1: The guest kernel can eject this paravirtual event.
+
+
+Ejecting paravirtual event
+======================
+kvm_pv_eject_event()
+Arguments:
+	event: The event to be ejected.
+
+Return Value:
+	None
diff --git a/arch/ia64/include/asm/kvm_para.h b/arch/ia64/include/asm/kvm_para.h
index 2019cb9..b5ec658 100644
--- a/arch/ia64/include/asm/kvm_para.h
+++ b/arch/ia64/include/asm/kvm_para.h
@@ -31,6 +31,20 @@  static inline bool kvm_check_and_clear_guest_paused(void)
 	return false;
 }
 
+static inline int kvm_arch_pv_event_init(void)
+{
+	return 0;
+}
+
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return 0;
+}
+
+static inline void kvm_arch_pv_eject_event(unsigned int event)
+{
+}
+
 #endif
 
 #endif
diff --git a/arch/powerpc/include/asm/kvm_para.h b/arch/powerpc/include/asm/kvm_para.h
index c18916b..01b98c7 100644
--- a/arch/powerpc/include/asm/kvm_para.h
+++ b/arch/powerpc/include/asm/kvm_para.h
@@ -211,6 +211,20 @@  static inline bool kvm_check_and_clear_guest_paused(void)
 	return false;
 }
 
+static inline int kvm_arch_pv_event_init(void)
+{
+	return 0;
+}
+
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return 0;
+}
+
+static inline void kvm_arch_pv_eject_event(unsigned int event)
+{
+}
+
 #endif /* __KERNEL__ */
 
 #endif /* __POWERPC_KVM_PARA_H__ */
diff --git a/arch/s390/include/asm/kvm_para.h b/arch/s390/include/asm/kvm_para.h
index da44867..00ce058 100644
--- a/arch/s390/include/asm/kvm_para.h
+++ b/arch/s390/include/asm/kvm_para.h
@@ -154,6 +154,20 @@  static inline bool kvm_check_and_clear_guest_paused(void)
 	return false;
 }
 
+static inline int kvm_arch_pv_event_init(void)
+{
+	return 0;
+}
+
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	return 0;
+}
+
+static inline void kvm_arch_pv_eject_event(unsigned int event)
+{
+}
+
 #endif
 
 #endif /* __S390_KVM_PARA_H */
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 2f7712e..7d297f0 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -96,8 +96,11 @@  struct kvm_vcpu_pv_apf_data {
 #define KVM_PV_EOI_ENABLED KVM_PV_EOI_MASK
 #define KVM_PV_EOI_DISABLED 0x0
 
+#define KVM_PV_EVENT_PORT	(0x505UL)
+
 #ifdef __KERNEL__
 #include <asm/processor.h>
+#include <linux/ioport.h>
 
 extern void kvmclock_init(void);
 extern int kvm_register_clock(char *txt);
@@ -228,6 +231,30 @@  static inline void kvm_disable_steal_time(void)
 }
 #endif
 
+static inline int kvm_arch_pv_event_init(void)
+{
+	if (!request_region(KVM_PV_EVENT_PORT, 1, "KVM_PV_EVENT"))
+		return -1;
+
+	return 0;
+}
+
+static inline unsigned int kvm_arch_pv_features(void)
+{
+	unsigned int features = inl(KVM_PV_EVENT_PORT);
+
+	/* Reading from an invalid I/O port will return -1 */
+	if (features == ~0)
+		features = 0;
+
+	return features;
+}
+
+static inline void kvm_arch_pv_eject_event(unsigned int event)
+{
+	outl(event, KVM_PV_EVENT_PORT);
+}
+
 #endif /* __KERNEL__ */
 
 #endif /* _ASM_X86_KVM_PARA_H */
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index c1d61ee..6129459 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -368,6 +368,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_pv_eject_event(KVM_PV_EVENT_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;
@@ -447,6 +458,20 @@  static void __init kvm_apf_trap_init(void)
 	set_intr_gate(14, &async_page_fault);
 }
 
+static void __init kvm_pv_panicked_event_init(void)
+{
+	if (!kvm_para_available())
+		return;
+
+	if (kvm_pv_event_init())
+		return;
+
+	if (kvm_pv_has_feature(KVM_PV_FEATURE_PANICKED))
+		atomic_notifier_chain_register(&panic_notifier_list,
+			&kvm_pv_panic_nb);
+}
+arch_initcall(kvm_pv_panicked_event_init);
+
 void __init kvm_guest_init(void)
 {
 	int i;
diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
index ff476dd..8e0fb81 100644
--- a/include/linux/kvm_para.h
+++ b/include/linux/kvm_para.h
@@ -20,6 +20,12 @@ 
 #define KVM_HC_FEATURES			3
 #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
 
+/* The bit of supported pv event */
+#define KVM_PV_FEATURE_PANICKED	0
+
+/* The pv event value */
+#define KVM_PV_EVENT_PANICKED	1
+
 /*
  * hypercalls use architecture specific
  */
@@ -33,5 +39,22 @@  static inline int kvm_para_has_feature(unsigned int feature)
 		return 1;
 	return 0;
 }
+
+static inline int kvm_pv_event_init(void)
+{
+	return kvm_arch_pv_event_init();
+}
+
+static inline int kvm_pv_has_feature(unsigned int feature)
+{
+	if (kvm_arch_pv_features() & (1UL << feature))
+		return 1;
+	return 0;
+}
+
+static inline void kvm_pv_eject_event(unsigned int event)
+{
+	kvm_arch_pv_eject_event(event);
+}
 #endif /* __KERNEL__ */
 #endif /* __LINUX_KVM_PARA_H */