| Message ID | 5021D235.4050800@cn.fujitsu.com |
|---|---|
| State | New |
| Headers | show |
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.
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
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
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.
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.
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.
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
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
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
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
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.
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
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.
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
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
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
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
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
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
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
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.
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
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
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/ >
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 */
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