Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
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 mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@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 majord...@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
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
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.
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Aug 14, 2012, at 10:35 PM, Anthony Liguori wrote: Marcelo Tosatti mtosa...@redhat.com writes: On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote: Marcelo Tosatti mtosa...@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 majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
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.
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
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 -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
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 -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
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 -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
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.
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
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.
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
Marcelo Tosatti mtosa...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote: Marcelo Tosatti mtosa...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
Marcelo Tosatti mtosa...@redhat.com writes: On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote: Marcelo Tosatti mtosa...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On 14 August 2012 19:53, Anthony Liguori anth...@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
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@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
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked\
On Tue, Aug 14, 2012 at 05:59:06PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@redhat.com writes:
On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
Marcelo Tosatti mtosa...@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
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
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 we...@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 000..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
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
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. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
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.
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
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 000..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.
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
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 000..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
[Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
We can know the guest is panicked when the guest runs on xen.
But we do not have such feature on kvm.
Another purpose of this feature is: management app(for example:
libvirt) can do auto dump when the guest is panicked. If management
app does not do auto dump, the guest's user can do dump by hand if
he sees the guest is panicked.
We have three solutions to implement this feature:
1. use vmcall
2. use I/O port
3. use virtio-serial.
We have decided to avoid touching hypervisor. The reason why I choose
choose the I/O port is:
1. it is easier to implememt
2. it does not depend any virtual device
3. it can work when starting the kernel
Signed-off-by: Wen Congyang we...@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 000..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)
+
